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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Terrestrial Trunked Radio (TETRA). 

The present document is part 3 of a multi-part deliverable covering Terrestrial Trunked Radio (TETRA); Voice plus 
Data (V+D), as identified below: 

Part 1: "General network design"; 

Part 2: "Air Interface (AI)"; 

Part 3: "Interworking at the Inter-System Interface (ISI)"; 

Part 4: "Gateways basic operation"; 

Part 5: "Peripheral Equipment Interface (PEI)"; 

Part 6: "Line connected Station (LS)"; 

Part?: "Security"; 

Part 9: "Supplementary services general design"; 

Part 10: "Supplementary services stage 1"; 

Part 11: "Supplementary services stage 2"; 

Part 12: "Supplementary services stage 3"; 

Part 13: "SDL model of the Air Interface (AI)"; 

Part 14: "Protocol Implementation Conformance Statement (PICS) proforma specification"; 

Part 15: "TETRA frequency bands, duplex spacings and channel numbering". 
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Scope 



The present document defines the Terrestrial Trunked Radio (TETRA) system supporting Voice plus Data (V+D). It 
specifies: 

general design aspects (e.g. reference points, numbering and addressing, or protocol architecture); 

the system bearer and mobility management services, and the corresponding air interface protocols; 

the interworking between TETRA networks; 

the interworking of TETRA networks with other networks, via gateways; 

the peripheral equipment interface on the mobile station; 

the Line Station (LS) interface with TETRA networks; 

the security protocols and mechanisms applicable to TETRA networks and to TETRA terminal equipment; 

the supplementary services applicable to the basic TETRA tele- or bearer services. 

The TETRA V+D interworking - basic operation part defines the interworking between TETRA networks over the 
corresponding interface: the Inter-System Interface (ISI). It comprises the following subparts: 

ISI general design; 

- Additional Network Feature - ISI Individual Call (ANF-ISIIC); 

- Additional Network Feature - ISI Group Call (ANF-ISIGC); 

- Additional Network Feature - ISI Short Data service (ANF-ISISD); 

- Additional Network Feature - ISI Mobility Management (ANF-ISIMM); 
8 kbit/s encoding of user information at the ISI. 

The present document is the ANF-ISIIC sub-part. 

ANF-ISIIC enables calls to be set-up by a user registered in one TETRA network to another user registered in another 
TETRA network, operating at the ISI of both SwMIs. It also supports call restoration when a user has migrated to 
another TETRA network during an established call. Additionally, ANF-ISIIC allows TETRA signalling information to 
be passed from a TETRA SwMI to another TETRA SwMI supporting the TETRA individual call procedures as defined 
in clauses 11 and 14 of EN 300 392-2 [1]. 

Like all other Additional Network Feature (ANF) specifications, those of ANF-ISIIC are produced in three stages, 
according to the method described in ITU-T Recommendation 1.130 [11]. The present document contains the stage 1 
and 2 descriptions of ANF-ISIIC, and its partial stage 3 description. The stage 1 description specifies the ANF as seen 
by its users, which are essentially the individual call control entities in both TETRA networks. The stage 2 description 
identifies the functional entities involved in the ANF and the information flows between them. And the partial stage 3 
description of ANF-ISIIC specifies its protocol. 

NOTE: According to ITU-T Recommendation 1.130 [11], the stage 3 description of a bearer or tele-service 

addresses the network implementation aspects. Consequently, it comprises two steps: the specifications of 
all protocols at the various reference points involved in any of the service procedures (notably the service 
operation) are the first step of the stage 3 description, and the specifications of the functions of the 
corresponding network entities are its second step. 

The latter have not been provided since they can be derived from the specification of the functional entity 
actions in the stage 2 description. 

The present document applies to TETRA networks which support inter-TETRA individual calls. More specifically, it 
applies to their Circuit Mode Control Entities (CMCE), as defined in subclause 14.2 of EN 300 392-2 [1], and to their 
ANF-ISIIC entities defined in the stage 2 description. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions of ETS 300 392-3-1 [2] apply, in addition to the 
following: 

originating SwMI or SwMI A: Switching and Management Infrastructure in which the calling user has registered 

called SwMI or SwMI B: Switching and Management Infrastructure to which ANF-ISIIC routes the first call attempt 

SwMI C: Switching and Management Infrastructure in which the called user has registered after having migrated from 
SwMI B, in the case where its home SwMI is SwMI B 

terminating SwMI: Switching and Management Infrastructure in which the connected user is registered 

NOTE 1: Unless an interaction with one or more supplementary services which modify the routing of the call (e.g. 
call forwarding) has occurred, the connected user will be the called user; and the terminating SwMI will 
be the SwMI where the called user is registered, i.e. SwMI B or SwMI C. 

forward switching: network routing algorithm which performs the routing from SwMI A to SwMI C by joining 
together the first connection, from SwMI A to SwMI B, and a second connection from SwMI B to SwMI C 

home SwMI: SwMI which is the home of the MS (or LS) ITSI, i.e. to which the Mobile Network Identity (MNI) which 
is part of the ITSI belongs 

re-routing: network routing algorithm which performs the routing from SwMI A to SwMI C by replacing the 
connection from SwMI A to SwMI B by another connection from SwMI A to SwMI C 

loop connection: ISI connection which has both its ends in the same SwMI 

trombone connection: special case of loop connection where all inter-TETRA connections making up the loop 
connection are used twice 

NOTE 2: If no interaction occurs with supplementary services which modify the routing of the call (e.g. call 

forwarding), the only loop connection which can be established by an invoked ANF-ISIIC is a trombone 
connection (i.e. when SwMI C coincides with SwMI A). 

3.2 Abbreviations 

For the purpose of the present document, the following abbreviations apply: 

CC Call Control (PISN functional entity) 

CCAp Call Control Application (SwMI functional entity) 

FE Functional Entity 

ISDN Integrated Services Digital Network 

ISI Inter System Interface 

ITSI Individual TETRA Subscriber Identity 

LS Line Station 

MNI Mobile Network Identity 

MS Mobile Station 

PDU Protocol Data Unit 

PINX Private Integrated Services Network Exchange 

PISN Private Integrated Services Network 

PSSl Private Integrated Signalling System Number 1 
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SDL Specification and Description Language 

SS-BIC Supplementary Service Barring of Incoming Calls 

SS-CAD Supplementary Service Call Authorized by Dispatcher 

SS-CCBS Supplementary Service Call Completion to Busy Subscriber 

SS-CCNR Supplementary Service Call Completion on No Reply 

SS-CF Supplementary Service Call Forwarding (general abbreviation for the call forwarding 

supplementary services) 

SS-CFB Supplementary Service Call Forwarding on Busy 

SS-CFU Supplementary Service Call Forwarding Unconditional 

SS-CFNRc Supplementary Service Call Forwarding on Not Reachable 

SS-CFNRy Supplementary Service Call Forwarding on No Reply 

SS-CLIR Supplementary Service Calling/connected Line Identification Restriction 

SS-CW Supplementary Service Call Waiting 

S S -HOLD Supplementary S ervice Call Hold 

SSI Short Subscriber Identity 

SwMI Switching and Management Infrastructure 



ANF-ISIIC stage 1 specification 



4.1 Description 

4.1.1 General description 

ANF-ISIIC enables individual calls to be set-up from a TETRA user registered in one Switching and Management 
Infrastructure (SwMI) to another TETRA user registered in another SwMI. ANF-ISIIC operates at the Inter System 
Interface (ISI) of both SwMI Call Control Applications (CCAps), in such a manner that these calls can be routed 
through (transit) Private Integrated Services Networks (PISNs). Additionally, for the duration of each call, ANF-ISIIC 
allows TETRA signalling information to be passed from TETRA SwMI to TETRA SwMI in accordance with the 
TETRA Individual Call procedures as defined in EN 300 392-2 [I]. In addition ANF-ISIIC participates in call 
restoration when a user has migrated to another TETRA network during an established call. 

The entities with which ANF-ISIIC interacts are the originating and the terminating SwMI CCAps, and in addition, 
some SwMI databases, especially that of the called user home SwMI. 

4.1 .2 Qualifications on applicability to telecommunication services 

ANF-ISIIC is applicable to all point-to-point circuit mode tele- and bearer services defined in EN 300 392-2 [1]: 

point-to-point TETRA clear mode speech; 

point-to-point TETRA end-to-end encrypted speech; 

point-to-point one slot 2,4 kbit/s, 4,8 kbit/s or 7,2 kbit/s TETRA circuit mode data; 

- point-to-point N x 2,4 kbit/s, N x 4,8 kbit/s or N x 7,2 kbit/s TETRA circuit mode data, with N = 2, 3 or 4; 

point-to-point end-to-end encrypted one slot 2,4 kbit/s, 4,8 kbit/s or 7,2 kbit/s TETRA circuit mode data; 

point-to-point end-to-end encrypted N x 2,4 kbit/s, N x 4,8 kbit/s or N x 7,2 kbit/s TETRA circuit mode data, 
with N = 2, 3 or 4. 



4.2 



Procedures 



4.2.1 Provision/withdrawal 

Provision of ANF-ISIIC shall always be available. 
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4.2.2 Normal procedures 

4.2.2.1 Activation/deactivation/registration/interrogation 

ANF-ISIIC shall always be activated. 

Registration and interrogation are not applicable to this ANF. 

4.2.2.2 Invocation and operation 

ANF-ISIIC shall be invoked by SwMI A CCAp, its served user, when a request from a TETRA user for an individual 
call to another TETRA network is received by this SwMI. The other network SwMI being called SwMI B by definition, 
SwMI A CCAp will identify SwMI B either: 

through analysis of the destination number when the called user home SwMI is SwMI B; or 

by a migration information when the called user home SwMI is SwMI A and this user has migrated to SwMI B. 

In either case, the invoked ANF-ISIIC shall route the call over an inter-TETRA connection to TETRA network B. 

ANF-ISIIC shall allow the use of a PISN to interconnect these two SwMIs. 

NOTE: This implies that ANF-ISIIC needs to be defined as an extension of PISN basic call control as defined by 
ISO/IEC 1 1574 [17] and 1 1572 [16]. This extension consists in the addition of certain procedures that 
PISN basic call control is unable to perform satisfactorily for TETRA networks, in remaining compatible 
with PISN inter-exchange signalling protocol as defined by ISO/IEC 1 1582 [18]. 

4.2.2.2.1 Call routing 

If the called user is registered in TETRA network B, SwMI B will know the location of this user; ANF-ISIIC shall then 
allow this SwMI to complete the call with this user, by ensuring the necessary transfer of information with SwMI A. 

If the called user has migrated to another SwMI (SwMI C), then ANF-ISIMM as defined in ETS 300 392-3-5 [3] will 
ensure that this is known from its home SwMI. 

NOTE: SwMI C cannot exist when the called user home SwMI is SwMI A. This is because when a user has 
migrated first in a given TETRA network 1, and then migrates into a new TETRA network, SwMI A 
database will now hold the identity of this new network as being that of SwMI B. 

Thus SwMI C as defined in subclause 3.1 will only exist when the home SwMI of the called user is 
SwMI B and when this user has migrated. 

Then the call shall be either re-routed (from SwMI A) or forward switched (through SwMI B), depending on the ANF 
mode of operation. 

The invoked ANF-ISIIC shall detect the specific case where SwMI C coincides with SwMI A. The ANF-ISIIC shall 
then instruct SwMI A to establish the call as an intra-TETRA call (i.e. avoiding a trombone connection) and clear itself. 

4.2.2.2.2 Control of call time-out timers 

Call time-out either for the call establishment phase or once the call has been established may be negotiated between 
SwMI A CCAp and the terminating SwMI (i.e. SwMI B or C) CCAp: for such negotiation SwMI A CCAp shall 
indicate its time-out for both durations, and the terminating SwMI CCAp should either use these values or if it decides 
to have a larger one for any of its corresponding timers, send it to SwMI A CCAp. SwMI A CCAp should then use the 
latter values (for its corresponding timers). 

NOTE: While the exchange of time-out values between the two CCAps has been specified in the protocol (see 

subclauses 6.3.1.1, 6.3.1.7, 6.3.1.8 and 6.3.1.14), the use of the time-out values of one CCAp by the other 
is optional. However if this other CCAp does not use them, the risk of call attempt failure (due to 
premature call establishment time-out) or call interruption (due to premature call duration time-out) will 
be increased. 
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4.2.2.2.3 Transmission control 



ANF-ISIIC shall remain operational for the duration of the call, sending and receiving TETRA signalling messages as 
appropriate under direction of the originating and terminating SwMI CCAps. 

The originating SwMI shall be designated as the controlling SwMI for half-duplex operation, and all requests to 
transmit from the called user shall be directed to this SwMI to be granted, after the call control application of the 
terminating SwMI shall have reserved the corresponding radio resource for the called user. 

4.2.2.2.3a Setup modification 

When being established the individual call may be changed into a group call. The invoked ANF-ISIIC shall then 
become ANF-ISIGC. Similarly a group call may be changed into an individual call. The invoked ANF-ISICG shall then 
become ANF-ISIIC. 

4.2.2.2.4 Call modification 

Call modification as defined in subclause 14.5.1.2 of EN 300 392-2 [1] shall have no impact on the basic ISI 
connection(s) (see table 1) established by the invoked ANF-ISIIC. 

NOTE 1: The reason for this is first that the various cases of call modification defined in subclause 14.5.1.2 of 
EN 300 392-2 [1] never cause to exceed the capacity of such basic ISI connection, and second, it is not 
possible to reduce the ISI connection information transfer rate defined at ANF-ISIIC set-up. 

However call modification shall result in a change in the 8 kbit/s encoding of the user information when the data rate of 
this information changes, because of e.g. a change from data call to speech call, or from 4,8 kbit/s to 7,2 or 2,4 kbit/s, 
and vice-versa. 

NOTE 2: The use of the optional ISI connection (see table 2) for call modification is outside the scope of the 
present document. 

4.2.2.2.5 Call restoration after migration 

If the calling or the called user migrates and registers in a new TETRA network once an inter-TETRA call has been 
established, ANF-ISIMM will be invoked to inform the call control application of the SwMI where this migrating user 
was previously registered (hereafter called the "old SwMI"). Upon request of that call control application, the 
ANF-ISIIC invoked to establish this call shall then establish a new connection between the old SwMI and the new 
SwMI, by putting the call on hold. The call restoration request by the migrating user in the new SwMI (see 
subclause 14.5.1.2.4 of EN 300 392-2 [1]) shall result in the held call being transferred by the old SwMI to this 
migrating user. This transfer shall be by join (i.e. through the old SwMI). It will result in a new connection (between the 
new network in which the user is now registered and the network where the other user engaged in the call remains 
registered) which shall be used by the existing ANF-ISIIC. 

NOTE 1 : Using re-routing for call restoration has been considered to be too complex. 

Figure 1 illustrates this in the case where the calling user has migrated and its home SwMI is not SwMI A. 
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Figure 1 : Call restoration by the calling user having migrated, 
with its home SwMI being different from SwMI A 

Similarly, if the same migration of the calling or of the called user happens once an inter-TETRA call in a given SwMI 
has been established, ANF-ISIMM will be invoked to inform the Call Control (CC) entity of this SwMI. This SwMI CC 
shall invoke ANF-ISIIC to allow a successful call restoration. 

NOTE 2: As opposed to the former case of call restoration, where ANF-ISIIC has already been invoked and is then 
extended to the "new" SwMI by transfer, the latter is a very specific case of ANF-ISIIC invocation. 

NOTE 3: When this migration takes place during the establishment of the call, the call will be cleared by the 
MS/LS, as a result of the detection of the corresponding (radio path) break by its MLE. 

NOTE 4: The term "migration" corresponds to what has been defined for GSM as "national roaming": i.e. changing 
from one GSM Public Land Mobile Network (PLMN) area to another one (see subclauses 2.3 and L2 of 
ETS 300 921 [7]). Thus, using the GSM terminology, TETRA call restoration while migrating would 
correspond (at least at the stage 1 description level) to "handover" while "roaming nationally", i.e. while 
leaving one GSM PLMN area and entering a new one. 



4.2.2.2.6 



Call clearing 



When clearing the call on its side, either the originating or the terminating SwMI call control applications shall clear the 
invoked ANF-ISIIC. This ANF-ISIIC shall then clear the ISI connection, and clear the other SwMI call control 
application. 

NOTE 1 : In the originating SwMI, the call may be cleared either by the calling user or by the call control 

application (e.g. if the SwMI can no longer support the call). Similarly, in the terminating SwMI, the call 
may be cleared either by the called user or by the call control application. 

NOTE 2: Although this is purely formal, since the interfaces between ANF-ISIIC and the call control application 
are internal to SwMIs, to be consistent with both the stage 1 description of the PISN basic call in 
ISO/IEC 11574 [17] and the definition of TETRA call control primitives in clause 11 of EN 300 392- 
2 [1], it will be considered that the clearings between the invoked ANF-ISIIC and the call control 
applications are acknowledged. 



4.2.2.2.7 



Interaction between ANF-ISIICs 



Due to the fact that a single ANF-ISIIC shall handle the routing of the call either to the called user, even when this user 
has migrated, only one ANF-ISIIC shall be invoked per individual call. And thus, no interaction can possibly take place 
in the case of a single individual call. 

As stated in the corresponding subclauses, this shall also hold in case of interactions with supplementary services, 
including those which modify the routing of the call (e.g. call forwarding, see subclauses 4.3.6 to 4.3.9). 
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On the other hand, two invoked ANF-ISIIC using or needing a connection between two given SwMIs can interact 
through some supplementary services: 

the include call supplementary service for merging two individual calls into a group call (see subclause 4.3.22); 

the Pre-emptive Priority Call supplementary service (see subclause 4.3.21) for the invocation of ANF-ISIIC for a 
new call, to choose whether to operate such newly invoked ANF-ISIIC in clearing an active one, or to reject it. 

4.2.3 Exceptional procedures 

4.2.3.1 Activation/deactivation/registration/interrogation 

Not applicable. 

4.2.3.2 Invocation and operation 

ANF-ISIIC may reject the call request with an appropriate failure indication for any of the following reasons: 

no inter-TETRA connection available, permanently; 

no inter-TETRA connection available, temporarily; 

failed call restoration (see subclause 4.2.2.2). 

In addition, if the called user has migrated and is now registered in SwMI A but that SwMI had not detected it and had 
thus invoked an ANF-ISIIC, that invoked ANF-ISIIC shall then inform that SwMI about it in avoiding that the call 
attempt be established with a trombone connection (see definition of that term in subclause 3.1). SwMI A call control 
application shall then clear the invoked ANF-ISIIC (and will establish the call as an intra-TETRA call). 

NOTE: According to the way ANF-ISIMM operates, the latter case cannot arise when the called user home SwMI 
is SwMI A, since in such a case SwMI A call control application would not have invoked ANF-ISIIC. 

The called user SwMI or the terminating SwMI shall clear the invoked ANF-ISIIC in the following cases: 

the called user address is incorrect or invalid; 

unsuccessful outcome of Private Integrated Signalling System Number 1 (PSSl) basic call establishment related 
to the called user as described in subclause 9.3 of ISO/IEC 11574 [17]; 

no details concerning the location of the called user are available or they are outdated. 

4.3 Interactions with other TETRA supplementary services and 
ANFs 

Interactions with other TETRA supplementary services and ANFs for which TETRA Standards were available at the 
time of publication of the present document are specified below. 

4.3.1 Calling Line Identification Presentation (SS-CLIP) 

No interaction. 

4.3.2 Connected Line identification Presentation (SS-COLP) 

No interaction. 

4.3.3 Calling/connected Line Identification Restriction (SS-CLIR) 

In an individual inter-TETRA call, both the originating and the terminating SwMIs shall support SS-CLIR for the user 
at the other end (e.g. the terminating SwMI shall support SS-CLIR for the calling user). 
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4.3.4 Call Report (SS-CR) 

No interaction. 

4.3.5 Talking Party Identification (SS-TPI) 

No interaction. 

NOTE: The fact that the ANF-ISIIC invoked for a call carries transparently SS-TPI signalling exchanged between 
the calling SwMI (A) call control application and the terminating SwMI (B/C) call control application is 
not to be considered as an interaction. 

4.3.6 Call Forwarding Unconditional (SS-CFU) 

Whenever ANF-ISIIC has been invoked, it shall interact with SS-CFU if the latter has been activated (e.g. by the called 
user, this user being the SS-CFU served user), unless the incoming call is barred to the called user - by the barring of 
incoming calls or the call authorized by dispatcher supplementary services. 

In addition, when the home SwMI of the called user is SwMI A, SS-CFU shall invoke ANF-ISIIC for forwarding the 
call if the forwarded-to user home SwMI is different from SwMI A, except possibly when the forwarded-to user 
happens to be registered in SwMI A after having migrated. 

The full specifications of the interactions between SS-CFU and ANF-ISIIC are given in subclause 5.6.5 of 
EN 300 392-12-4 [9]. 

When the called user home SwMI is SwMI A, the main interaction is the invocation of ANF-ISIIC already mentioned. 
When the called user home SwMI is SwMI B, the interactions can be summarized as follows: 

unless the called user has migrated and is now registered in SwMI A, the ANF-ISIIC originally invoked for 
attempting to route the call to the called user shall invoke SS-CFU if it has been activated (in SwMI B) and that 
ANF-ISIIC shall ensure SS-CFU routing if the forwarded-to user is registered in another SwMI; 

if the called user has migrated and is now registered in SwMI A, then the invoked ANF should check whether 
another SS-CFU, a local SS-CFU, has been activated in SwMI A for the called user, and if so, it shall not invoke 
the SS-CFU activated in the home SwMI (thus letting SwMI A CMCE invoke this local SS-CFU). 

Still if the called user has migrated and is now registered in SwMI A, if SS-CFU has been activated in the home 
SwMI for that user and no local SS-CFU, in SwMI A for that same user, then SwMI A call control application 
shall invoke ANF-ISIIC even if it can route directly calls to called users registered in that SwMI when it is not 
their home SwMI (i.e. as intra-TETRA calls). The invoked ANF-ISIIC shall itself invoke the SS-CFU activated 
in the home SwMI; 

if the forwarded-to user has itself activated a call forwarding unconditional supplementary service towards 
another forwarded-to user and if an ANF-ISIIC had already been invoked, that invoked ANF-ISIIC shall invoke 
that new call forwarding supplementary service and operate its routing. It shall do so as for the previous SS-CFU 
provided that: 

the new forwarded-to user home SwMI is considered as the new SwMI B; 

if the new forwarded-to user has migrated, the SwMI where he is registered is considered as the new 
SwMI C; and 

the last SwMI on the path through which the call attempt has been forward switched is considered as the new 
SwMI A, i.e. if the new SS-CFU is only the second one, that last SwMI shall be: 

the originating SwMI if only rerouting has taken place; 

the home SwMI of the new SS-CFU served user if the call attempt has been forward switched through it; 
or if different from the previous ones; 

the home SwMI of the first SS-CFU served user, i.e. the originally called user; 
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if the forwarded-to user has itself activated another call forwarding supplementary service than the call 
forwarding unconditional supplementary service towards another forwarded-to user registered in another SwMI 
and if an ANF-ISIIC had already been invoked it shall ensure the further routing of the call attempt if necessary, 
according to the specification of the interaction between ANF-ISIIC and that other call forwarding 
supplementary service specified in the corresponding subclause below provided that: 

the new forwarded-to user home SwMI is considered as the new SwMI B; 

if the new forwarded-to user has migrated, the SwMI where he is registered is considered as the new 
SwMI C; and 

the last SwMI on the path through which the call attempt has been forward switched is considered as the new 
SwMI A, i.e. if the new call forwarding supplementary service is only the second call forwarding 
supplementary service invoked for the call, that last SwMI shall be: 

the originating SwMI if only rerouting has taken place; 

the home SwMI of the forwarded-to user for the new call forwarding if the call attempt has been forward 
switched through it; or if not 

the SwMI where the forwarded-to user for the initial SS-CFU is currently registered if the call attempt has 
been forward switched through it; or if different from the previous ones (e.g. if the forwarded-to user for 
the initial SS-CFU had migrated); 

the home SwMI of the initial SS-CFU served user, i.e. the originally called user; 

when ensuring the SS-CFU routing mentioned above, the invoked ANF-ISIIC shall avoid loop connection 
(notably trombone connection) between the originating and the terminating SwMIs (e.g. SwMI where the 
forwarded-to user is registered coinciding with SwMI A). 

In addition, the invoked ANF-ISIIC shall operate the barring of incoming calls supplementary service not only for the 
originally called user when that user is a SS-CFU served user but for each SS-CFU forwarded-to user (i.e. the SS-CFU 
forwarded-to user if only one call forwarding unconditional supplementary service is operated for the call, and each of 
them if many call forwarding unconditional supplementary services are operated for the call). 

NOTE: No requirement is included in subclause 5.6.5 of EN 300 392-12-4 [9], on the interaction between the call 
forwarding supplementary services (SS-CF) and SS-BIC, because such interaction has no impact on the 
definition of SS-CF protocol. 



4.3.7 Call Forwarding on Busy (SS-CFB) 



The interactions between SS-CFB and ANF-ISIIC are similar to those between SS-CFU and ANF-ISIIC, with the main 
difference that whereas ANF-ISIIC invoked SS-CFU, it shall not invoke SS-CFB: SS-CFB will be invoked by the 
CMCE entity of the SwMI where its served user is registered (if it has been activated and if that user is busy). 

NOTE 1: Thus when the SS-CFB served user has migrated, contrary to SS-CFU, SS-CFB is not invoked in the 
served user home SwMI. 

Another difference, which is a consequence of the main one mentioned above, is that ANF-ISIIC shall not operate any 
SS-BIC activated for a SS-CFB served user, whether the originally called user or the forwarded-to user for a SS-CF 
invoked just previously. 

The full specifications of these interactions are given in subclause 5.6.5 of EN 300 392-12-4 [9]. They are summarized 
below: 

when the called user is registered in another SwMI than SwMI A, i.e. SwMI B or SwMI C, and that SwMI has 
invoked SS-CFB (the called user being thus busy) the same ANF-ISIIC invoked for routing the call attempt from 
SwMI A to that other SwMI (SwMI B or SwMI C) shall further route the call towards the SwMI where the 
forwarded-to user is registered when that SwMI is different from the SwMI where the called user is registered 
(SwMI B or SwMI C). The same ANF-ISIIC invoked for routing the call attempt from SwMI A to that SwMI 
may also be used to further route the call in the specific case where the forwarded-to user happens to be 
registered in that same SwMI after having migrated (i.e. that SwMI is not the forwarded-to user home SwMI but 
its call control application cannot route directly calls to called users registered there when it is not their home 
SwMI, i.e. as intra-TETRA calls); 
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when the called user is registered in SwMI A, ANF-ISIIC shall be invoked for routing the call the SwMI where 
the forwarded-to user is registered if that SwMI is different from SwMI A. It may also be invoked for routing the 
call attempt from SwMI A to the forwarded-to user home SwMI in the specific case where the forwarded-to user 
happens to be registered in SwMI A after having migrated (i.e. SwMI A is not the forwarded-to user home SwMI 
but its call control application cannot route directly calls to called users registered there when it is not their home 
SwMI, i.e. as intra-TETRA calls). 

NOTE 2: In that specific case where the called user is registered in SwMI A, another SS-CFB, a local SS-CFB, may 
have been activated in that SwMI. It will then be up to the CMCE entity of that SwMI to invoke that local 
SS-CFB instead of the general one. Once that local SS-CFB will have been invoked, ANF-ISIIC will be 
invoked for routing the call to the forwarded-to user exactly as if the general SS-CFB had been invoked 
with the same forwarded-to user. 

if the forwarded-to user has itself activated a call forwarding on busy supplementary service towards another 
forwarded-to user, if an ANF-ISIIC had already been invoked it shall further route the call attempt if necessary 
as for the previous SS-CFB provided that: 

the new forwarded-to user home SwMI is considered as the new SwMI B; 

if the new forwarded-to user has migrated, the SwMI where he is registered is considered as the new 
SwMI C; and 

the last SwMI on the path through which the call attempt has been forward switched is considered as the new 
SwMI A, i.e. if the new SS-CFB is only the second one, that last SwMI shall be: 

the originating SwMI if only rerouting has taken place; 

the home SwMI of the new SS-CFB forwarded-to user if the call attempt has been forward switched 
through it; or if not 

the SwMI where the new SS-CFB has been invoked if the call attempt has been forward switched through 
it; or if not and if if different from the previous ones (e.g. if the new SS-CFB served user, i.e. the 
forwarded-to user of the first SS-CFB, had migrated); 

the home SwMI of the new SS-CFB served user if the call attempt has been forward switched through it; 
or if not and if different from the previous ones; 

the SwMI where the first SS-CFB has been invoked if the call attempt has been forward switched through 
it; or if not and if different from the previous ones (e.g. if the first SS-CFB served user, i.e. the originally 
called user, had migrated); 

the home SwMI of that originally called user; 

if the forwarded-to user has itself activated a call forwarding unconditional supplementary service and 
ANF-ISIIC had already been invoked for the routing of the call attempt, that ANF-ISIIC shall invoke this new 
supplementary service and operate its routing according to subclause 4.3.6, provided that: 

the new forwarded-to user home SwMI is considered as the new SwMI B; 

if the new forwarded-to user has migrated, the SwMI where he is registered is considered as the new 
SwMI C; and 

the last SwMI on the path through which the call attempt has been forward switched is considered as the new 
SwMI A, i.e. if the new SS-CFU is only the second call forwarding supplementary service invoked for the 
call, that last SwMI may be: 

the originating SwMI if only rerouting has taken place; 

the home SwMI of the new SS-CFU forwarded-to user if the call attempt has been forward switched 
through it; or if not 

the home SwMI of the new SS-CFU served user, i.e. the forwarded-to user of the initial SS-CFB, if the 
call attempt has been forward switched through it; or if not and if different from the previous ones; 
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the SwMI where the initial SS-CFB has been invoked if the call attempt has been forward switched 
through it; or if not and if if different from the previous ones (e.g. if the initial SS-CFB served user, i.e. 
the originally called user, had migrated); 

the home SwMI of that originally called user; 

when ensuring the SS-CF routing mentioned above, this invoked ANF-ISIIC shall avoid loop connection 
(notably trombone connection) between the originating and the terminating SwMIs (e.g. SwMI where the 
forwarded-to user is registered coinciding with SwMI A). 

In addition, the invoked ANF-ISIIC shall operate the barring of incoming calls supplementary service not only for the 
originally called user when that user is a SS-CFB served user but for each SS-CFB forwarded-to user (i.e. the SS-CFB 
forwarded-to user if only one call forwarding on busy supplementary service is operated for the call, and each of them if 
many call forwarding on busy supplementary services are operated for the call). 

NOTE 3: See note 2 in subclause 4.3.6 above. 

4.3.8 Call Forwarding on No Reply (SS-CFNRy) 

The interactions between SS-CFNRy and ANF-ISIIC shall be the same as those between SS-CFB and ANF-ISIIC (see 
subclause 4.3.7 above). 

NOTE: The specification above that the interactions between SS-CFNRy and ANF-ISIIC are be the same as those 
between SS-CFB and ANF-ISIIC is valid only for the stage 1 description. Notably this not true for the 
specification of the ANF-ISIIC protocol (since in the case of SS-CFNRy operation with an ANF-ISIIC 
already invoked a PSSl ALERTING message is sent before a possible PSSl FACILITY message 
carrying an ANF-ISIIC re-routing PDU). 

4.3.9 Call Forwarding on Not Reachable (SS-CFNRc) 

The are two cases for the invocation and operation of SS-CFNRc: 

when the served user home SwMI has been previously informed that the SS-CFNRc served user is not reachable 
(e.g. he has deregistered). This case is qualified in subclause 5.6.4 of EN 300 392-12-4 [9] as "early" CFNRc; 

when it is only when attempting to set-up the call to the SS-CFNRc served user, as called party, that the SwMI 
where that user is registered finds out that such user is not reachable. This case is qualified in subclause 5.6.4 of 
EN 300 392-12-4 [9] as "late" CFNRc. 

This interactions between SS-CFNRc and ANF-ISIIC shall be the same as the same as those: 

between SS-CFU and ANF-ISIIC (see subclause 4.3.6 above) in the case of "early" CFNRc; and 

between SS-CFB and ANF-ISIIC (see subclause 4.3.7 above) in the case of "late" CFNRc. 

4.3.1 List Search Call (SS-LSC) 

No interaction. 
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NOTE 1: SS-LSC will interact with SwMI A CC, which itself will invoke the ANF for calling a user in the list. But 
this is not an interaction between ANF-ISIIC and SS-LSC. 

NOTE 2: The statement that there shall be no interaction implies that the choice has been made to invoke 

ANF-ISIIC every time a call is attempted to the next user (registered in another SwMI) in SS-LSC list 
(i.e. ruling out the possibility of invoking ANF-ISIIC only once for two consecutive users in this list, in 
the case where these two users would be registered in the same SwMI). 

4.3.1 1 Call Authorized by Dispatcher (SS-CAD) 

SS-CAD shall interact with ANF-ISIIC as follows: 

for source restricted calls, the SS-CAD control entity in the originating SwMI shall invoke ANF-ISIIC when 
SS-CAD operation requires that the outgoing call be diverted to the dispatcher and when this dispatcher is 
located in a SwMI different from the SwMI in which the restricted (calling) user is registered (i.e. this dispatcher 
would then be able to discuss with the calling user before allowing or not the establishment of the requested call, 
as opposed to a simple authorization based only on sending to this dispatcher the calling and called numbers by 
signalling); 

NOTE 1 : The call establishment will then be suspended by the originating SwMI call control and supplementary 
service control applications. 

once the dispatcher has approved the call, if a call had been established with this dispatcher, the ANF-ISIIC 
invoked towards the dispatcher shall transfer the call to the called user; 

NOTE 2: If no call has been established with a dispatcher, SS-CAD will request the SwMI call control and 
supplementary service control applications which suspended the call establishment to resume it. 

for destination restricted calls, the same procedure as for source restricted calls shall apply for the calls for which 
ANF-ISIIC has not already been invoked. This shall be the case for intra-TETRA calls either source restricted 
but with a "local" dispatcher, or not source restricted. It shall also be the case for inter-TETRA calls to a called 
user who has migrated with his home SwMI being the originating SwMI; 

for destination restricted inter-TETRA calls to a called user the home SwMI of which is the called SwMI (i.e. the 
called user SwMI is not SwMI A, but SwMI B), the invoked ANF-ISIIC shall invoke and operate SS-CAD. 
Notably when this operation requires that the incoming call be diverted to the dispatcher and when this 
dispatcher is located in a SwMI different from the called SwMI, this ANF-ISIIC shall divert the call to the 
dispatcher. If this call is authorized by SS-CAD, this ANF-ISIIC shall transfer the call to the called user in re- 
routing it from the called user home SwMI (i.e. SwMI B). And if in addition the called user has migrated to 
SwMI A, the invoked ANF-ISIIC shall pass the necessary information to call control and supplementary service 
control applications of this SwMI e.g. so that no local SS-BIC may be invoked for this call; 

NOTE 3: If SS-CAD has been activated for both the outgoing call and the incoming call, it will be invoked 
separately for each. 

NOTE 4: In the special case where the called user (has migrated and) is now registered in SwMI A and where 

SwMI A call control application can route directly (i.e. without invoking ANF-ISIIC) calls to called users 
registered in this same SwMI when it is not their home SwMI (i.e. they have migrated), SwMI A call 
control and supplementary service control applications need to be informed about the activation of 
SS-CAD in the called user home SwMI, to invoke it. This is why ANF-ISIMM will ensure that whenever 
a user which has activated SS-CAD in his home SwMI migrates to another network, the SwMI of this 
other network will be informed about this SS-CAD activation. 

contrary to its normal operation, ANF-ISIIC shall make no attempt to avoid any trombone connection or more 
generally loop connection in routing the diverted call to the dispatcher from SwMI B; 

NOTE 5: The reason for this is that the resulting re-routing would by-pass SwMI B, wherefrom the ANF-ISIIC call 
establishment will continue after it has been authorized by the dispatcher; this continuation being either 
by transfer: 

internal to SwMI B if the called user has not migrated; 

by forward switching in SwMI B if the called user has migrated to another SwMI than SwMI A; or 
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by transfer with re-routing in SwMI A if the called user has migrated into SwMI A. 

if the call has been diverted to the dispatcher, after the dispatcher has authorized the call establishment to be 
resumed, the SS-CAD diverting SwMI shall ensure that the transmission permission granting to the terminating 
SwMI does not result in any change for the originating SwMI call control application, i.e.: 

if the calling user had been granted permission to transmit when the dispatcher authorizes the call to be 
resumed, the diverting SwMI shall ensure that the set-up message that it is sending to the terminating SwMI 
does not grant transmission permission to the called user; 

if it is the dispatcher who had been granted permission to transmit when the dispatcher authorizes the call to 
be resumed, the diverting SwMI shall ensure that the set-up message that it is sending to the terminating 
SwMI grants transmission permission to the called user; 

when the originating SwMI call control application receives the response from the terminating SwMI after the 
call has been diverted to a dispatcher, it shall act as if the call had not been diverted for all applicable 
supplementary services which it supports, e.g. SS-CLIP, SS-COLP, SS-CLIR, SS-TPI, SS-CCBS and SS-CCNR. 
This shall hold even if for the originating SwMI does not support SS-CAD. 

4.3.12 Short Number Addressing (SS-SNA) 

No interaction. 

4.3.13 Area Selection (SS-AS) 

No interaction. 

4.3.14 Access Priority (SS-AP) 

No interaction (since SS-AP applies only locally at the radio access). 

4.3.15 Priority Call (SS-PC) 

If SS-PC has been activated, ANF-ISIIC shall interact with SS-PC if this operates by queuing for accessing inter- 
TETRA connection(s) necessary for its routing. Such interaction shall consist in having every newly invoked ANF- 
ISIIC competing with the other invoked ANF-ISIIC and ANF-ISIGC still in the inter-TETRA connection allocation 
queue, when the number of those connections available has fallen below a certain threshold. In such a case, it shall 
inform SwMI A CC about this. 

NOTE: In the case where there is a risk of congestion due to an insufficient number of inter-TETRA connections 
between two SwMIs for the offered traffic, it would be recommended to split these inter-TETRA 
connections into two groups, one of which would be reserved to priority calls (i.e. these calls could be 
routed on any connection of the two groups, while the "ordinary" could only be routed on a connection of 
the second group). 

If SS-PC has been invoked for the call and if SwMI B supports SS-PC, in the case where the ANF-ISIIC invoked for 
this same call routes it to SwMI C by forward switching, such queuing shall be operated first in SwMI A, and second in 
SwMI B. 

4.3.16 Call Waiting (SS-CW) 

No interaction. 

4.3.17 Call Hold (SS-HOLD) 

No interaction. 
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4.3.1 8 Call Completion to Busy Subscriber (SS-CCBS) 

When the calling user and the called user are registered in different SwMIs, SS-CCBS shall invoke an ANF-ISIIC for 
its operation, either for (SS-CCBS) path reservation, or if the latter is not implemented (by SS-CCBS), when the call to 
the called user is reinitiated. 

NOTE: When the called user migrates while remaining busy (e.g. its established call is restored - see subclause 
4.2.2.2), all SS-CCBS pending invocations (i.e. not yet completed or cancelled) to this called user will be 
passed to the new SwMI where this user has registered. But this passing is not an interaction between 
SS-CCBS and ANF-ISIIC, since it will not be done by the latter. 

4.3.19 Late Entry (SS-LE) 

No interaction (since SS-LE does not apply to TETRA individual calls). 

4.3.20 Transfer of Control (SS-TC) 

No interaction (since SS-TC does not apply to TETRA individual calls). 

4.3.21 Pre-emptive Priority Call (SS-PPC) 

SS-PPC shall interact with ANF-ISIIC to pre-empt the inter-TETRA connection with the lowest Call Retention Value 
(CRV) among those which may be used to route the priority call. SS-PPC shall operate such pre-emption first in forcing 
the clearing of this inter-TETRA connection (with its normal operation for the connected parties to be released), and 
then in invoking a new ANF-ISIIC at the corresponding ISI. 

NOTE: If inter-TETRA connections between the originating SwMI and the terminating one are not direct, but are 
established by transit through a PISN, it would desirable that this PISN offers some mechanism to assess 
the priority level of each possible inter-TETRA connections between these two SwMIs. 



4.3.22 Include Call (SS-IC) 



SS-IC and ANF-ISIIC shall interact whenever the SS-IC served user is engaged with a user registered in a different 
SwMI in an individual call to be included in a group call (by SS-IC). 

The requirement for this interaction is to be able to change the call bearer capability from point-to-point (for the 
individual call) into point-to-multipoint. Such change shall be controlled by SS-IC. 

In the case where the other user engaged in an individual call with the served user, is not the only group call participant 
registered in its SwMI, either the inter-TETRA connection established by ANF-ISIIC for this individual call shall be 
released, or it shall be used for the new group call. 

In addition whatever SwMI was controlling the simplex transmission in the individual call shall release this control to 
the controlling SwMI of the new group call. 



4.3.23 Advice of Charge (SS-AoC) 



When SS-AoC-E and ANF-ISIIC have both been invoked for a call (i.e. delivery of charging information at the end of a 
call has been requested for an inter-TETRA call, or an external call routed over the ISI), both shall interact in the case 
where the served user wants to clear the call. In such a case, the SwMI which is controlling the served user shall not 
clear the invoked ANF-ISIIC. Instead, it shall request this invoked ANF-ISIIC to ensure the delivery of charging 
information for this call. Only after it has got such information, shall the invoked ANF-ISIIC clear the call, in ensuring 
that this information is transferred to the SwMI which is controlling the served user. 

The same shall apply when SS-AoC-D and ANF-ISIIC have both been invoked for a call (since SS-AoC-D delivers 
charging information at the end of a call). 



£75/ 



24 ETSI TS 100 392-3-2 V1.1.1 (2000-10) 

4.3.24 Barring of Outgoing Calls (SS-BOC) 

No interaction. 

NOTE: SS-BOC is operated by SwMI A call control and supplementary service control applications. 

4.3.25 Barring of Incoming Calls (SS-BIC) 

No interaction when the called user home SwMI is SwMI A (i.e. SS-BIC shall be invoked and operated by SwMI A call 
control and supplementary service control applications). 

When the called user home SwMI is SwMI B, the ANF-ISIIC invoked to establish the call with the called user shall 
invoke SS-BIC, except in the special case presented below. 

In the special case where the called user (has migrated and) is now registered in SwMI A, where it has activated another 
SS-BIC in SwMI A for intra-TETRA calls and where SwMI A call control application has invoked ANF-ISIIC to 
establish the call with the called user, then this ANF-ISIIC shall operate as follows: 

it shall check whether a local SS-BIC has been activated; 

if so, it shall by-pass the invocation of the home SwMI SS-BIC (i.e. if a local SS-BIC has been activated, the 
home SwMI SS-BIC will not be invoked for this special case of intra-TETRA call) in invoking and operating 
this local SS-BIC; 

only if no local SS-BIC has been activated, shall the invoked ANF-ISIIC invoke and operate the home SwMI 
SS-BIC; 

if the operation of the relevant SS-BIC results in having the call barred, the invoked ANF-ISIIC shall clear the 
call; 

if the operation of the relevant SS-BIC results in having the call authorized, there shall be no more interaction 
between SS-BIC and ANF-ISIIC. 

NOTE 1: As stated in subclause 4.2.3.2, the invoked ANF-ISIIC will clear itself in informing SwMI A call control 
application about the situation. 

NOTE 2: On the other hand another issue arises if SwMI A call control application can route directly (i.e. without 
invoking ANF-ISIIC) calls to called users registered in this same SwMI when it is not their home SwMI 
(i.e. they have migrated). This issue is that, if no local SS-BIC has been activated, SwMI A call control 
and supplementary service control applications needs to be informed about the activation of SS-BIC in 
the called user home SwMI, to invoke it. This is why ANF-ISIMM will ensure that whenever a user 
which has activated SS-BIC in its home SwMI migrates to another network, the SwMI of this other 
network will be informed about this SS-BIC activation. 

NOTE 3: When SS-CAD has also been activated for the called user (see subclause 4.3. 1 1), its invocation will take 
precedence over that of SS-BIC, according to the definition of the interaction between these two 
supplementary services - in ETS 300 392-10-19 [8]. 



4.3.26 Discreet Listening (SS-DL) 



When SS-DL has been invoked, if the user being listened to and the monitoring user are registered in two different 
SwMIs, SS-DL shall invoke an ANF-ISIIC for its operation. 

Only one ANF-ISIIC shall be invoked by SS-DL, even when the call being listened to by the invoked SS-DL is an inter- 
TETRA individual call. 

NOTE: In the latter case, SS-DL will use a listening bridge in the SwMI where the user being listened to is 
registered, so that the same invoked ANF-ISIIC will be used independently of which user is 
talking/sending. 

But in the specific case where the other party engaged in the inter-TETRA individual call being listened to by the 
invoked SS-DL is registered in the same SwMI as the listening user, SS-DL shall still use a specifically invoked 
ANF-ISIIC for its operation. 
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4.3.27 Ambience Listening (SS-AL) 

Then the SS-AL served user (i.e. the monitoring party) monitors an MS/LS registered in a given SwMI, if this user is 
registered in a different SwMI, SS-AL shall invoke an ANF-ISIIC for its operation. 

4.3.28 Dynamic Group Number Assignment (SS-DGNA) 

No interaction (since SS-DGNA is not applicable to individual calls). 

4.3.29 Gall Completion on No Reply (SS-CCNR) 

When the calling user and the called user are registered in different SwMls, SS-CCNR shall invoke an ANF-ISIIC for 
its operation, either for (SS-CCNR) path reservation, or if the latter is not implemented (by SS-CCNR), when the call to 
the called user is reinitiated. 

NOTE: When the called user migrates, all SS-CCNR pending invocations (i.e. not yet completed or cancelled) to 
this called user will be passed to the new SwMI where this user has registered. But this passing is not an 
interaction between SS-CCNR and ANF-ISIIC, since it will not be done by the latter. 



4.3.30 Call Retention (SS-CRT) 



SS-CRT shall interact with the ANF-ISIIC in having the Call Retention Value (CRV) of the call for which both have 
been invoked assigned to the inter- TETRA connection(s) over which this call will have been routed. 

4.3.31 Additional Network Feature Inter System Interface Group Call 
(ANF-ISIGC) 

The only interactions between ANF-ISIGC and ANF-ISIIC shall be through the include call supplementary service (see 
subclause 4.3.22). 

NOTE: Even when all "group participants" but one have left a group call (i.e. only the group call owner and the 

last "group participant" are remaining in the call active state), the call remains a group call - so as to allow 
the easy introduction of a new (participant) user in this group. 

4.3.32 Additional Network Feature Inter System Interface Short Data 
Service (ANF-ISISD) 

No interaction. 

4.3.33 Additional Network Feature Inter System Interface Mobility 
Management (ANF-ISIMM) 

No interaction. 

NOTE 1: Even in the case of call restoration, ANF-ISIMM does not interact with ANF-ISIIC: it interacts only with 
the call control application of the SwMI concerned - and it is this call control application which interacts 
with ANF-ISIIC. 

NOTE 2: All updating of the SwMI databases used for the operation of ANF-ISIIC are not to be considered as 
interactions between ANF-ISIMM and ANF-ISIIC. 

4.3.34 Additional Network Feature Inter System Interface Supplementary 
service (ANF-ISISS) 

No interaction. 

NOTE: The fact the ANF-ISISS can be invoked for carry such supplementary service information together with 
some specific TETRA basic call one (e.g. in the TETRA set-up message) is not an interaction. 
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4.4 Interworking considerations 



ANF-ISIIC and PSTN shall interwork in the case of PSTN call through a TETRA gateway located in a SwMI different 
from that where the TETRA user involved in this call is registered. For an outgoing call (i.e. from a TETRA calling 
user), SwMI A call control application will invoke an ANF-ISIIC to route the call over an ISI to the PSTN gateway. 
This ANF shall send to SwMI B call control application the PSTN called number (received from SwMI A call control 
application), and indicate whether the call is a telephony call or a data call (through a bearer service request). In the 
latter case, the gateway will use a modem belonging to its modem pool for the duration of the call. Before ensuring the 
data exchange between the PSTN and the gateway SwMI, this modem will first establish (automatically) the call to the 
called user modem and negotiate the data rate with the latter modem. 

NOTE 1 : A TETRA speech (tele-) service call will result in a standard PSTN telephony call. But a TETRA data 
service call to a PSTN may result in a TETRA bearer service negotiation, depending on the modem rate 
negotiation between the modem of the PSTN called user and the PSTN gateway modem. 

For an incoming telephony call (i.e. to a TETRA called user), the PSTN calling user will have to send the number of the 
called user to the TETRA PSTN gateway. This will be done using DTMF (in-band) dialling. After the gateway has 
detected the DTMF digits it will convert the corresponding decimal number into an ITSI or GTSI number. Then if the 
analysis made by the call control application of the SwMI where this gateway is located shows first that the SSI of the 
called user corresponds to an ITSI number, and not to a GTSI one (i.e. the type of call requested is an individual call 
and not a group call), and second that the called user is registered in another SwMI, this will result in a standard 
invocation of an ANF-ISIIC to extend the individual call requested to the called user. This ANF will use the ITSI 
number converted from the received DTMF digits as the called number. 

NOTE 2: A PSTN telephony call will result in a TETRA speech (tele-) service call. 

A similar procedure will apply for an incoming data call, with the difference that this call would first be connected by 
the gateway to some modem. 

NOTE 3: The DTMF addressing procedure is not compatible with the standard procedures for automatic calls by 
modems. 

NOTE 4: For such data calls from PSTN, TETRA bearer service negotiation will be possible with the called SwMI 
or the TETRA called user, but only if the called SwMI can inform fast enough the gateway modem on the 
bearer service that it supports (otherwise the negotiation phase between the two modems involved in the 
call establishment - one on the calling party side, the other, part of the PSTN gateway modem pool - will 
be over). 

ANF-ISIIC and Integrated Services Digital Network (ISDN) shall interwork in the case of ISDN call through a TETRA 
gateway located in a SwMI different from that where the TETRA user involved in this call is registered. 

For an outgoing call (i.e. from a TETRA calling user), the interworking will be the same as that between ANF-ISIIC 
and PSTN, in replacing PSTN number by ISDN number: SwMI A call control application will invoke an ANF-ISUC to 
route the call over an ISI to the ISDN gateway. This ANF shall send to SwMI B call control application the ISDN called 
number (received from SwMI A call control application). Only the PSTN numbering plan will be used for this ISDN 
called number (since there is no means for the calling user to indicate any other numbering plan, neither to indicate any 
corresponding type of number). For a data call, instead of a modem procedure, the rate adaptation procedure defined in 
ITU-T Recommendation V.llO [15] will be used. The data rate for the call might then be negotiated using the (optional) 
in-band parameter exchange (IPE) procedure described in appendix I of this recommendation. 

NOTE 5: ITU-T Recommendation V. 110 [15] , of September 1992, has been recently updated and republished as 
an ITU-T Recommendation V.llO [15]. While ITU-T Recommendation V.l 10 [15] did not support 28,8 
kbit/s rate, ITU-T Recommendation V.l 10 [15] does (i.e. referring to ITU-T Recommendation V.l 10 [15] 
instead of ITU-T Recommendation V. 1 10 [15] would have resulted in the impossibility to support 
TETRA 4 X 7,2 kbit/s (= 28,8 kbit/s) bearer service). 

NOTE 6: A TETRA speech (tele-) service call will result in an ISDN telephony tele-service. Similarly a TETRA 
data service call will result in an ISDN 64 kbit/s with the following bearer service attribute values: 
information transfer capability value equal to unrestricted digital information, and layer 1 access protocol 
value corresponding to the rate adaptation in accordance with ITU-T Recommendation V.l 10 [15]. 
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For an incoming call (i.e. to a TETRA called user), contrary to the case of a PSTN calling user, the ISDN calling user 
can send the address of the called user to the TETRA ISDN gateway. It will do this using one of the various means 
available (e.g. using the ISDN supplementary services sub-addressing or user to user signalling). And this calling user 
can also indicate the type of call, telephony or data call, through the bearer service requested. 

NOTE 7: An ISDN telephony tele-service will result in a TETRA speech (tele-) service call. And an incoming 
ISDN call requesting a bearer capability defined by an information transfer capability value equal to 
unrestricted digital information, and a layer 1 access protocol value corresponding to the rate adaptation 
in accordance with ITU-T Recommendation V.llO [15], will result in a TETRA data call. 

The data rate for the call might then be negotiated using the (optional) IPE procedure described in appendix I of this 
ITU-T Recommendation V.llO [15]. 

ANF-ISIIC and PISN shall interwork in the case of PISN call through a TETRA gateway located in a SwMI different 
from that where the TETRA user involved in this call is registered. This interworking shall be exactly the same as that 
described above between ANF-ISIIC and ISDN, in replacing ISDN number by PISN number. 

NOTE 8: The fact that ANF-ISIIC allows to use PISN to interconnect the SwMIs involved in inter-TETRA 
individual calls is not to be considered as interworking at stage 1 level. 

NOTE 9: Another possibility to make an external outgoing call is first to establish an inter-TETRA call with the 
gateway, and then to send the called number digits (by the DTMF air interface information elements) to 
this gateway (i.e. two stage dialling, already mentioned in subclause 14.5.1.2.5 of EN 300 392-2 [1]). It 
has not been addressed above, since from a formal point of view, it can hardly be considered as a true 
interworking case. 

4.5 Static description of ANF-ISIIC using attributes 

In accordance with ITU-T Recommendation 1.210 [13], the static description of ANF-ISIIC is given below using the 
relevant attributes with the corresponding values as defined in ITU-T Recommendation 1.140 [12]. 

ANF-ISIIC is extending over the ISI the TETRA bearer or tele- service invoked by an individual call calling user, by 
creating the necessary connection between the originating and the terminating SwMIs. The corresponding bearer service 
attributes are given in annex A, which is informative (since it is simply reformulating the corresponding information 
defined in EN 300 392-2 [1]). 

Using the terminology defined in ITU-T Recommendation 1.140 [12], the connection to be created by ANF-ISIIC as a 
result of its invocation and operation is a connection element. 

Table 1 defines the static description of this connection element in terms of the values of its attributes as listed in ITU-T 
Recommendation 1.140 [12]. 

As an option another set of values is defined in table 2 for networks which can handle multirate 8 kbit/s calls (i.e. 
networks which first can handle 8 kbit/s - instead of or in addition to the standard 64 kbit/s channels, and second can 
establish calls involving more than one such channel). 

NOTE 1 : The attributes in tables 1 and 2 have been grouped into categories in a similar manner as in ITU-T 
Recommendation 1.210 [13] for the bearer service attributes. 

As already stated in subclause 4.2.2.2, call modification shall have no impact on the connection(s) established by the 
invoked ANF-ISIIC, but it shall result in a change in the 8 kbit/s encoding of the user information when the data rate of 
this information changes. Thus the access attribute Information transfer coding/protocol in the static descriptions of the 
ISI connection elements in tables 1 and 2 may change when a call modification occurs. No other attribute in these tables 
shall change. 

NOTE 2: This means that even if the ISI connection has been established as an N x 8 kbit/s connection (see 

table 2), the number N of 8 kbit/s ISI channels used for the call will not change. The reason for this is first 
that the various cases of call modification defined in subclause 14.5.1.2 of EN 300 392-2 [1] never result 
in an increased number of ISI 8 kbit/s channels, and second, the definition of PISN multirate calls does 
not cater for the possibility of reducing the number of channels used for the call at set-up time. 

As to the case of 64 kbit/s connection elements, addressed in table 1, obviously there is no possibility to 
change the information transfer rate of these connection elements. 
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Table 1 : Basic definition of ANF-ISIIC connection element attributes 



Attribute category 


Attribute name 


Attribute value 


information transfer 
attributes 


1 . Information transfer mode: 

2. Information transfer rate: 

3. Information transfer capability: 

4. Structure: 

5. Establishment of connection: 

6. Symmetry: 

7. Connection configuration: 


circuit 

64 kbit/s 

no restriction (see note) 

8 kHz integrity 

demand 

bi-directional symmetric 

point-to-point 


Access attributes 


8. Channel: 

9. Connection control protocol: 

10. Information transfer coding/ 
protocol: 


Bq for user information, 

Dq for signalling 

PSS1 for DQ-channel 

Encoding of each TETRA slot into an 8 kbit/s 
stream. In case of a (TETRA) multi-slot bearer 
service, the resulting 8 kbit/s streams shall be 
multiplexed as defined in ITU-T 
Recommendation 1.460 [19]. 


Generai attributes 


1 1 . Network performance: 

12. Network interworking: 

13. Operations and management 
aspects: 


for further study 
for further study 

for further study 


NOTE: According to tlie definition of the attribute information transfer capability of a connection element in ITU-T 
Recommendation 1.140 [12], the value of this attribute for the ANF-ISIIC connection element should be 
"null". Since this value means that there is no restriction to the types of information which may pass 
through the connection element, the term "no restriction" has been preferred. 



Table 2: Optional definition of ANF-ISIIC connection element attributes 



Attribute category 


Attribute name 


Attribute value 


information transfer 
attributes 


1 . Information transfer mode: 

2. Information transfer rate: 

3. Information transfer capability: 

4. Structure: 

5. Establishment of connection: 

6. Symmetry: 

7. Connection configuration: 


circuit 

N X 8 kbit/s (with n = 1 , 2 ,3 or 4) 

no restriction (see note) 

time slot sequence integrity (TSSI) 

demand 

bi-directional symmetric 

point-to-point 


Access attributes 


8. Channel: 

9. Connection control protocol: 

10. Information transfer coding/ 
protocol 


8 kbit/s channels for user information, 
Dq for signalling 

PSS1 for DQ-channel 

Encoding of each TETRA slot into an 8 kbit/s 
stream 


General attributes 


1 1 . Network performance: 

12. Network interworking: 

13. Operations and management 
aspects: 


for further study 
for further study 

for further study 


NOTE: According to the definition of the attribute information transfer capability of a connection element in ITU-T 
Recommendation 1.140 [12], the value of this attribute for the ANF-ISIIC connection element should be 
"null". Since this value means that there is no restriction to the types of information which may pass 
through the connection element, the term "no restriction" has been preferred. 
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4.6 Overall SDL 



Figure 2 contains the dynamic description of ANF-ISIIC using the Specification and Description Language (SDL) 
defined in ITU-T Recommendation Z.IOO [14]. The SDL process represents the behaviour of the set of SwMI entities 
involved, interconnected by the intervening network, possibly by a PISN, in providing ANF-lSllC. 

Output/input signals from/to the left represent primitives from/to SwMl A CC. Output/input signals from/to the right 
represent primitives from/to the CC of the SwMl in which the called user is registered (i.e. SwMl C in the case of re- 
routing or forward switching, and SwMI B otherwise), except in the case of forward switching where some output/input 
signals from/to the right represent primitives from/to SwMI B CC. The latter are to establish first the second leg of 
forward switching and then SwMI B transit operation. 
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Figure 2 (sheet 1 of 5): ANF-ISIIC, overall SDL 
Main diagram 
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Figure 2 (sheet 2 of 5): ANF-ISIIC, overall SDL 
Main diagram 
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Figure 2 (sheet 5 of 5): ANF-ISIIC, overall SDL 

Invocation of ANF-ISIIC because of migration 
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ANF-ISIIC stage 2 specification 



5.1 



Functional model 



5.1.1 



Functional model description 



The functional model shall comprise the following functional entities (FE): 

FEl SwMI A individual call control application functional entity; 

FBI' New SwMI call restoring functional entity for migrating calling user; 

FE2 ISI individual call originating functional entity; 

FE2' ISI individual call new originating functional entity; 

FE3 ISI individual outgoing call route determining functional entity; 

FE4 ISI individual call migration handling functional entity; 

FES ISI migration information provision functional entity; 

FE6 ISI migrated called user routing functional entity; 

FE7 ISI individual call terminating functional entity. 

FE7' ISI individual call new terminating functional entity; 

FES Terminating SwMI individual call control functional entity; 

FES' New SwMI call restoring functional entity for migrating called user. 
The following functional relationships shall exist between these FEs: 

ra between FEl and FE2; 

rb between FE2 and FE3 

re between FE2 and FE4 

rd between FE4 and FES 

re between FE4 and FE6 

rf between FE6 and FE7 

rg between FE2 and FE7 

rh between FE7 and FES 

ri between FEl and FES 

rj between FE2 and FE2 

rk between FEl' and FE2 

rl between FE7 and FE7' 



or between FES' and FE7'; 



Figure 3 shows these FEs and relationships in the case where the called user home SwMI is different from the 
originating SwMI (i.e. the called user home SwMI is SwMI B). 
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Figure 3: Functional model for ANF-ISIIC 
when the called user home SwMI is different from the originating SwMI 

Figure 4 shows these FEs and relationships in the case where the called user home SwMI is the originating SwMI (i.e. 
the called user home SwMI is SwMI A). 
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NOTE: Even though it is not a functional entity of ANF-ISIIC in this case (see subclause 5.1 .2.4), FE4 has been 
shown in figure 4 to avoid showing a direct relationship between FE1 and FE6. 

Figure 4: Functional model for ANF-ISIIC 
when the called user home SwMI is the originating SwMI 
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5.1 .2 Description of functional entities 

5.1 .2.1 SwMI A individual call control application functional entity, FE1 

This functional entity invokes ANF-ISIIC when it receives a set-up information flow from a calling user (at its air 
interface) requesting the establishment of a call to another user which to its knowledge is registered in another TETRA 
network. It relays to the called user the call establishment response information flow(s) received from FES through FE7 
and FE2 (and possibly FE6 and FE4). Once the call has been established, it ensures call maintenance (as defined in 
subclause 14.1.2 of EN 300 392-2 [1]) for the calling user in exchanging related control information flows with FES for 
the necessary co-ordination. 

If FEl is informed by ANF-ISIMM that the calling user is now registered in another network (where the calling user 
would have migrated during the call), it shall request FE2 to establish a connection leg with FEl' through FE2', both 
newly created. After the call has been once transferred (following the call restoration request by the calling user) 
between FEl', in the other network, and FES, FEl shall be cleared, and FEl' shall then become the new FEl. 

5.1 .2.2 ISI individual call originating functional entity, FE2 

This functional entity ensures an ISI outgoing gateway function for individual calls from SwMI A call control 
application. This includes the following capabilities: 

the ability to establish an individual call upon request of FEl and release it notably upon request of FEl ; 

the ability to associate and mediate between FEl and the subsequent PISN CC functional entity involved in a 
particular call and between FEl and FES, notably to transfer to FES any information received from FEl (i.e. ISI 
end-to-end information), and vice versa; 

the ability, when the called user home SwMI is SwMI B and when this user has migrated to SwMI C, to decide, 
possibly on the basis of the information received from FE4, either to re-route the call over another ISI or to have 
it forward switched (in SwMI B); 

unless SwMI C coincides with SwMI A (i.e. the called user has migrated in the same SwMI as the originating 
one and the CC entity of the latter was not capable of identifying this), in which case FE2 shall ensure the 
interactions with local SS-BIC, SS-CAD and SS-CF if activated for intra-TETRA calls (in SwMI A), taking into 
account the information received from FE4 regarding the activation of those supplementary services also for the 
called user but in his home SwMI. If the call is not forwarded, FE2 shall clear the invoked ANF-ISIIC, with or 
without clearing the call, depending on whether or not the call is barred by the above mentioned incoming call 
restriction supplementary services. 

Upon request from FEl (to prepare for call restoration), FE2 shall establish a connection leg with FEl' through FE2', 
both newly created. Once informed by FEl' that the calling user has requested call restoration, FE2 shall ensure the 
transfer of the call between FEl' through FE2' and FES. FE2' shall then become the new FE2. 

5.1 .2.3 ISI Individual outgoing call route determining functional entity, FES 

This functional entity: 

provides to FE2, or FE6 in the case where the called user home SwMI is the originating SwMI, information to 
route the individual call (over the ISI) to SwMI B; 

provides to FE2 information about activations and "definitions" (the latter term corresponding to the term 
"registrations" as defined in ITU-T Recommendation 1.130 [11]) of local SS-BIC, SS-CAD and SS-CF. 
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5.1 .2.4 ISI individual call migration handling functional entity, FE4 

This functional entity ensures the handling of individual calls incoming from FE2 when the home SwMI of the called 
user is SwMI B. This includes the following capabilities: 

the ability to operate as a Private Integrated Services Network Exchange (PINX) node incoming side; 

the ability to ensure the interactions with the supplementary services SS-BIC, SS-CAD and SS-CF if activated 
for the called user, the first two, to restrict his incoming calls, and the last one, to forward his calls. Notably FE4 
shall ensure together with FE2 the specific interactions which apply in the case where the called user has 
migrated in the originating SwMI (i.e. SwMI C coincides with SwMI A); 

the ability, if the called user has migrated, to indicate to FE2: 

in which SwMI the called user is registered now (i.e. SwMI C), on the basis of the information received from 
FES; 

whether or not forward switching is possible; and 

to detect whether SwMI C coincides with SwMI A; 

the ability, if FE2 requests FE4 to forward switch the call, to operate as the incoming side of a transit PINX (the 
outgoing side of which is ensured by FE6). 

When the called user home SwMI is SwMI A (i.e. this user has migrated and is now registered in SwMI B), FE4 will 
coincide with FEl (i.e. as part of SwMI A call control application and not of ANF-ISIIC). This is because first any 
interaction with SS-BIC, SS-CAD or SS-CF activated for the called user shall then be ensured by SwMI A 
supplementary service control applications, and not by ANF-ISIIC; and second, SwMI A call control application has to 
know that the called user has migrated and where it is currently registered (i.e. SwMI B) to invoke ANF-ISIIC to extend 
the call. 

5.1 .2.5 ISI information provision functional entity, FE5 

This functional entity: 

provides information to FE4 about activations and "definitions" (the latter term corresponding to the term 
"registrations" as defined in ITU-T Recommendation 1.130 [11]) of general SS-BIC, SS-CAD and SS-CF; 

if the called user has migrated to TETRA network C, provides this information to FEi4. 

5.1 .2.6 ISI individual call migrated called user routing functional entity, FE6 

This functional entity ensures the routing of individual calls to called users which have migrated. When the called user 
home SwMI is different from the originating SwMI, depending on FE2 decision and possibly on its own decision, either 
FE6 shall be located in SwMI A, and the call shall then be re-routed (from SwMI A), or FE6 shall be located in 
SwMI B, and the call shall then be forward switched (by SwMI B). FE6 includes the following capabilities: 

for re-routing the call, the ability to supplement FE2 in sending a set-up information flow to FE7 after having got 
the necessary routing information to route the call (over the ISI) to SwMI C; 

for forward switching the call, the ability to operate as the outgoing side of a transit PINX, the incoming side of 
which is ensured by FE4. As in the case of re-routing, that ability implies to have got the necessary routing 
information to route the call (over the ISI) to SwMI C. 

When the called user home SwMI is the originating SwMI (see subclause 5.1.2.4), FE6 shall replace FE2 to establish 
the call. 
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5.1 .2.7 ISI individual call terminating functional entity, FE7 

This functional entity ensures an ISI incoming gateway function for individual calls towards FES. This includes the 
following capabilities: 

the ability to establish an individual call to FES upon request of FE6 and release it notably upon request of FES; 

the ability to associate and mediate between FES and the subsequent PISN CC functional entity involved in a 
particular call and between FES and FEl, notably to transfer to FEl any information received from FES (i.e. end- 
to-end information), and vice versa. 

When FE6 does not exist, FE7 shall be collocated with FE4. 

NOTE: According to subclause 5.1.2.6, FE6 does not exist when the called user is registered in its home SwMI 
(which implies, since an ANF-ISIIC has been invoked, that this called user home SwMI is SwMI B). 

Upon request from FES (to prepare for call restoration), FE7 shall establish a connection leg with FES' through FE7', 
both newly created. Once informed by FES' that the connected user has requested call restoration, FE7 shall ensure the 
transfer of the call between FES' through FE7', and FEl. FE7' shall then become the new FE7. 

5.1 .2.8 Terminating SwMI call control functional entity, FES 

This functional entity ensures the establishment of the call to the called user according to the invoked ANF-ISIIC set-up 
information flow. It informs FEl through FE7 and FE2 (and possibly FE6 and FE4) about the completion (or failure) of 
this call establishment. Once the call has been established, it ensures call maintenance (as defined in subclause 14.1.2 of 
EN 300 392-2 [1]) for the connected user, exchanging related control information flows with FEl for the necessary co- 
ordination. 

If FES is informed by ANF-ISIMM that the connected user is now registered in another network (where this user would 
have migrated during the call), it shall request FE7 to establish a connection leg with FES' through FE7', both newly 
created. After the call has been transferred (following the call restoration request by the connected user) between FES', 
in the other network, and FEl, FES shall be cleared, and FES' shall become the new FES. 

5.1 .3 Relationship of functional model to basic call functional model 

By definition, an invoked ANF-ISIIC establishes a PISN basic call. As a result its functional model matches closely that 
of PISN basic call (as defined in ISO/IEC 11574 [17]): 

FEl shall be collocated with the originating PISN CC; 

FE2 shall also be collocated with the originating PISN CC (i.e. in SwMI A ANF-ISIIC outgoing gateway - 
gateway which may be virtual); 

FE4 together with FE6 shall be collocated in a transit PISN CC in the case of forward switching; 

FE7 shall be collocated with the terminating PISN CC (i.e. in the ANF-ISIIC incoming gateway of terminating 
SwMI - gateway which may be virtual); 

FES shall also be collocated with the terminating PISN CC. 

Figures 5, 6, 7 and S show examples of the relationship between the two models in the cases: 

where the home SwMI of the called user is SwMI B and where this user is registered in its home SwMI, for 
figure 5; 

where the home SwMI of the called user is SwMI A (and where this user is registered in SwMI B), for figure 6; 

where the called user has migrated (to SwMI C), and the call has been forward switched (in SwMI B), for 
figure 7; 

where the called user has migrated (to SwMI C), and the call has been re-routed (in SwMI A), for figure S. 
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Figure 5: Example relationship between models for ANF-ISIIC and basic call 
in the case of called user hSwMI being SwMI B, with no migration 
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Figure 6: Example relationship between models for ANF-ISIIC and basic call 
in the case of called user hSwMI being SwMI A 
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Figure 7: Example relationship between models for ANF-ISIIC and basic call 
in the case of forward switching 




Figure 8: Example relationship between models for ANF-ISIIC and basic call 

in the case of re-routing 



5.2 



Information flow 



5.2.1 Examples of information flow sequences 

The stage 3 description of ANF-ISIIC provides signalling procedures in support of the information flow sequences 
specified below. 

The figures have been drawn as Message Sequence Charts (MSC) using the SDT tool. Due to this, it has not been 
possible to show the stage 1 primitives (shown on stage 1 overall SDL, in figure 2) nor to represent ANF-ISIIC 
information flows independently from basic call (i.e. PISN basic call) information flows (e.g. with an ellipse embracing 
one ANF-ISIIC and one PISN basic call information flows to indicate that the two information flows occur 
simultaneously, or having an ANF-ISIIC information flow between two functional entities which are not adjacent - e.g. 
end-to-end, while the PISN basic call information flows are always between two adjacent functional entities). Simply 
when an ANF-ISIIC information flow occurs together with a PISN basic call information flow, the name of the latter is 
shown below the corresponding arrow, and the originating and the terminating functional entities of the arrow are those 
of the ANF-ISIIC information flow. 

NOTE: The names used for the PISN basic call information flows are those defined in ISO/IEC 1 1574 [17], on 
the stage 1 and 2 description of PISN basic call. And whenever possible (i.e. when such primitives exist), 
the names which have been given to the ANF-ISIIC information flows are those of the corresponding 
TNCC primitives, as defined in clause 11 of EN 300 392-2 [1]. 
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The following abbreviations are used: 
req request 
ind indication 
resp response 
conf confirmation 

5.2.1 .1 Successful call set-up when the called user is registered in SwMI B and uses 

on/off hook signalling 

Figure 9 shows the information flow sequence for ANF-ISIIC call set-up when the called user uses on/off hook 
signalling and when its home SwMI is SwMI B and it has not migrated. 

The information flow sequence corresponding to the case where the called user home SwMI is SwMI A (and this user 
has migrated and is registered in SwMI B) can be derived from figure 9 in replacing FE2 by FE6/FE2, and FE4/FE7 by 
FE7. 
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NOTE: The ISI-IC-SETUP PROLONGATION and -CHARACTERISTIC CHANGE request/indication information flows shown on the figure are optional. 

Figure 9: Information flow sequence - successful call set-up using on/off hook signalling 
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5.2.1 .2 Successful call set-up when the called user is registered in SwMI B and uses 

direct set-up signalling 

Figure 10 shows the information flow sequence for ANF-ISIIC call set-up when the called user uses direct set-up 
signalling and when its home SwMl is SwMI B and it has not migrated. 



MSC Successful_call_setup_direct_setup 



Originating 

SwIVII CCAp 

FE1 



ISI outgoing Originating SwIVII 
gateway database Transit CC 

FE2 I I FE3 I 



ISI incoming Terminating SwMI Terminating 
gateway database SwMI CCAp 



FE4/FE7 



FES 



FES 



ISI-IC-SETUP_req_ind 



ISI-ICINFOI^M1_resp_conf 



ISI-IC-CFIARACT. CHGE_recLind 



ISI-IC-SETUP_resp_conf 



ISI-IC-SET UP PROLONG._req_ind 



ISI-ICINFORM 1_req_ind 



ISI-IC-SETUP_req_ind 



(SETUP_req_inc 



ISI-IC-COMPLETE_recLinl$l-IC-COMPLETE_req_ind 



( CH/iN ACK_req_ind) 



ISI-IC-CHARACT 



ISI-IC- INFORM 2_conf_resp 



ISI-IC-SETUP_resp_conf 



( SETUP_resp_conf) 
idl-IC-SETUP PROLONG._req_indlSI-IC-SETUP PRQLONG._req_ind 



ISI-IC- INFORM 



2_req_hd 



ISI-IC-SETUP_req_ind 



CHGE_req_ind ISI-IC-CHARACT. CHGE_req_ind 



ISI-IC-COMPLETE_req_ind 



ISI-IC-SETUP_resp_conf 



Figure 10: Information flow sequence - successful call set-up using direct set-up signalling 

The information flow sequence corresponding to the case where the called user home SwMI is SwMI A (and this user 
has migrated and is registered in SwMI B) can be derived from figure 10 in replacing FE2 by FE6/FE2, and FE4/FE7 
by FE7. 
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5.2.1 .3 ANF-ISIIC set-up to a called user having migrated from SwIVII B, using 
forward switching 

Figure 1 1 shows the beginning of the information flow sequence for ANF-ISIIC call set-up when the called user has 
migrated from SwMI B, its home SwMI, and when SwMI A has indicated in the rb_SETUP request/indication 
information flow that it wants to choose the routing method in case of migration of the called user, and decides to have 
the call forward switched (in SwMI B) as a result of the indication in the rb_MIGRATION INFO request indication 
information flow. 

5.2.1 .4 ANF-ISIIC set-up to a called user having migrated from SwMI B, using 
re-routing 

Figure 12 shows the beginning of the information flow sequence for ANF-ISIIC call set-up when the called user has 
migrated from SwMI B, its home SwMI, and when SwMI A has indicated in the rb_SETUP request/indication 
information flow that it wants to choose the routing method in case of migration of the called user, and decides to 
re-route the call as a result of the indication in the rb_MIGRATION INFO request indication information flow. 
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MSC Successful_call_setup_nnigration_forward_switching 



lA 



I I 



Originating 
SwMI CCAp 

feI 



Originating SwMI 
ISI outgoing gateway database 



Transit CC Galled user hSwMI 



Called userhSwMI 

database Called user hSwMI 



FE2 



FES 



FE4 



FES 



ISi-IC SETUP_req_ind 



ISI-ICINFORM 1_resp_conf 



e- 



rSETUP_req_ind] 



ISI-IC INFORM 1 



-^ 



ISI-IC-SETUP_req_ind 



ISI-IC-MIGRATIC N_resp_conf 



req_ind 



Ch AN ACK_req_ind 
ISI-IC-MiqRATION_req_ind" 



IS 



ISI-IC-INFORM 2_req_ind 



-^ 



ISI-IC- 
INFORM 2_resp_conf 



ISI-IC-INFORM 1_req_ind 



■IC— INFORM 1_resp_conf 



ISI-IC-SETUP_req_ind 



FE6 



ISI incoming 
gateway 

FE7 



Terminating 
SwMI CCAp 

FE8 



ISI-IC-SETUP_req_ind 



rSETUP_req_indl 



ISI-IC-SETUP_req_ind 



Figure 1 1 : Information flow sequence - call set-up to a called user having migrated from SwMI B, using forward switching 
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MSC Successful_call_setup_migration_rerouteing 






Originating 
SwIVII CCAp 

FE1 



Originating SwMI 
ISI outgoing gateway database 



I FE2/FE6" 



ISI-IC-SETUP_req_ind 



ISI-IC INFORIVI 1_resp_conf 



e- 



] [ 



FE3 I 



ISI-IC INFORM 1 



ISI-IC-SETUP_r6q_ind 



SETUP_req_inl 



ISI-IC INFORM 1 



ISI-IC INFDRM 1_resp_conf 



ISI-IC-SETUP re 



SETUP_req_ind I 



ISI-IC-MIGRATI' 3N_resp_conf 



rRELEASE_req_ir 



Transit CC Called user hSwMI 
I I FE4 I 



Called user hSwMI ISI incoming 
database gateway 



FES 



req_ind 



ISI-IC-MIG RATION_req_ind 



.reqjnd 



Lind 



'\ 



[' 



RE 



RELEASE 



_resp_confl 



] 



:EASE_resp_conf 



ISI-IC-INFORM 2_req_ind 
^ 

ISI-IC- 
INFORM 2_resp_conf 



Terminating 
SwMI CCAp 



FE7 



FES I 



ISI-IC-SETUP_r sqjnd 



Figure 12: Information flow sequence - call set-up to a called user having migrated from SwMI B, using re-routing 
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5.2.1.5 



Loop avoidance in case of intra-TETRA call 



Figure 13 shows the information flow sequence when the home SwMl of the called user is SwMI B and when this user 
is registered in the originating SwMI, after having migrated. The invoked ANF-ISIIC is then cleared, and the 
information passed to SwMI A to continue the call as an intra-TETRA call. 

MSC Loop_detection_intra_TETRA_call 



Originating Originating SwIVII 

SwIVII CCAp ISI outgoing gatew ay database 

FE1 I I FE2 I I FE3 



Transit CC 



Called user hSwMI 
FE4 



Called user hSwMI 
database 



ISI-ICSETUP_req_ind 



ISI-IC INFORM 1_resp_conf 



ISI-IC INFORM 3_resp_conf 
ISI-IC-TROMBONE_reqJnd 



ISI-IC INFORM 1 



ISI-IC-SETUP_r3q_ind 



(SETUP_reqJnd 



(RELEASE_req. 



(REl 
ISI-IC INFORM 



/eqjnd 



( CHKn ACK__reqJnd: 
ISI-IC-TR0I\^1 BONE_reqJ nd 



ind) 



L&\SE 



_resp_conf) 
Lreqjnd 



(RE;LEASE_req_ind 



FES 



ISI-IC-INFORM 2_req_ind 



ISI-IC- 
INFORM2_resp_conf 



Figure 13: Information flow sequence - loop avoidance in case of intra-TETRA call 



5.2.1.6 



Unsuccessful ANF-ISIIC call set-up 



Figure 14 shows the information flow sequence for an unsuccessful ANF-ISIIC call set-up when the call attempt is 
rejected either by the terminating SwMI CC entity or by the called user. 
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MSC Unsuccessful_call_setup 



Originating 

SwMI CCAp 

FE1 



I SI outgoing 

gateway 

FE2 



Originating SwIVII 

database 

FES 



Transit CC 



ISI-IC-SETUP_req_ind 



ISI-IC INFOF^IVI 1_resp_conf 



ISI-IC-RELEASE_req_ind 



ISI-IC INFORM 



1 _req_ind 



ISI-IC -SETUP_req_ind 



(SETUP_req_incl) 



{RELEASE_resp. 



ISI incoming 
gateway 
FE4/FE7 



(CH/^N 
ISI-IC 



_conf) 



RE-EAS 



(RE-EASE_req_ind) 



(RELEASE_resp_oonf 



Terminating 

SwMI CCAp 

FES 



ISI-IC-SETUP_req_ind 



ACK_req_ind) 

E_req_ind lBl-IC-RELEASE_req_ind 



NOTE: The call set-up may also be rejected directly by the called SwMI, e.g. when it cannot match the air 

interface security level requested for the call. The corresponding information flow sequence has not been 
shown because it can easily be derived from figure 15. 

Figure 14: Information flow sequence - call rejected by the terminating SwMI or by the called user 

Figure 15 shows the information flow sequence for an ANF-lSllC call set-up rejected by the called SwMI (i.e. SwMI B) 
as a result of the information provided by FES. 
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MSC Call_setup_rejection 



I 



Originating 
SwIVII CCAp 

feI 



Originating SwMI 
ISI outgoing gateway database 



Transit CC Called user hSwMI 



FE2 



FES 



FE4/FE7 



Called user hSwMI 
database 

I FE5 I 



ISI-IC-SETUP_reqJnd 



ISI-IC-RELEASE_reqJnd 



ISI-IC INFORM 1_reqjnd 



ISI-IC INFORM 1 
_resp_conf 



ISI-IC-SETUP_reqJnd 



rSETUP_req_indl 



e- 



rRELEASE_resp_ 



ISI-IC 



[' 



;onf 



CHAN ACK_reqJnd 
^ELEASE_reqJnd 



R ELEASE_reqJnd 



^ 



rRELEASE_resp_ 



ISI-IC-INFORM 2_reqjnd 



-^ 



ISI-IC- 
INFORM 2_resp_conf 



;onfl 



NOTE: In line with ISO/IEC 1 1574 [17], on the stage 1 and 2 descriptions of PISN basic call, the RELEASE 
information flows have been shown as confirmed information flows on this figure. However, the 
corresponding PSS1 protocol may operate differently: notably if the call is rejected before a PSS1 
responding message has been sent, the PSS1 RELEASE request shall not be acknowledged (this 
corresponds to the ANF-ISIIC incoming gateway having rejected the call set-up with a PISN message 
RELEASE COMPLETE - see subclause 10.2 of ISO/IEC 1 1572 [16]). 

Figure 15: Information flow sequence - call rejected by the called SwMI 
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5.2.1.7 Transmission control 

Figure 16 shows the information flow sequence for half-duplex operation, when the called user requests to transmit. 



MSC Half_duplex_operation 



lA 



Originating 
SwMI CCAp 

FE1 



IS! outgoing gateway 



FE2 



ISI-IC-TX CEASED_reqJnd 



ISI-IC-TX GRANTED_reqJnd 



ISI-IC-INTERRUPT_reqJnd 



ISI incoming 
gateway 

FE7 



Terminating 
SwMI CCAp 



IS 



FES I 



-IC-TX DEMAND_reqJnd 



NOTE: All information flows which shown in figure 16 are across relationship ri, i.e. end-to-end between FE1 and 
FES. 

Figure 16: Information flow sequence - half-duplex operation 
with the called user requesting to transmit 
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5.2.1.8 Call modify 

Figure 17 shows the information flow sequence for call modification, when the modification request comes from the 
originating SwMl. 



MSC Call_modify 



u 



Originating 
SwIVII CCAp 

FE1 



ISI outgoing gateway 



FE2 



ISI incoming 
gateway 

FE7 



Terminating 
SwMI CCAp 

FE8 



ISI-IC-MODIFY_reqJnd 



ISI-IC-MODIFY_resp_conf 



ISI-IC-MODIFY_reqJnd 



ISI-IC-MODIFY_resp_conf 



ISI-IC-MODIFY_reqJnd 



ISI-IC-MODIFY_resp_conf 



ISI-IC-MODIFY_reqJnd 



ISI-IC-MODIFY_resp_conf 



ISI-IC-MODIFY_reqJnd 



SI-IC-MODIFY_resp_conf 
i 



ISI-IC-MODIFY_reqJnd 



ISI-IC-MODIFY_resp_con 
) 



NOTE: The MODIFY information flows are not end-to-end between the originating and the terminating SwMI 

because they may result in a change in the 8 kbit/s encoding of the user information at the ISI, i.e. if the 
circuit mode service is modified, i.e. from speech to data service or vice-versa, or if the circuit mode 
service being data service, this service is changed, e.g. from 7,2 kbit/s to 4,8 kbit/s. 

Figure 17: Information flow sequence - call modification 
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5.2.1 .9 Call restoration after migration 

Figure 18 shows the information flow sequence for call restoration in a new SwMI. 



MSC Call restoration new SwMI 



Old SwMI CCAp 

I ^^ I 



ISI gateway 



New SwMI ISI gateway 



New SwMI CCAp 



FE2 



FE2' 



FET 



ISI-IC-CALL RESTORE 
PREPARE_req_ind 



rSETUP_req_indl 



^ 



ISI-IC-RELEASE_req_ind 



ISI-IC-CALL RESTORE 
PREPARE_req_ind 



SETUP_resp_conf 



ISI-IC-CALL 
RESTORE_req_ind 



ISI-IC-CALL 
RESTORE_req_ind 



ISI-IC-CALL RESTORE 
PREPARE_req_ind 



ISI-IC-CALL 
RESTORE_req_ind 



Other end SwMI Other end 

gateway SwMI CCAp 



FE7 



FES 



ISI-IC-CALL 
RESTORE_req_inb 



Figure 18: Information flow sequence - call restoration of an established inter-TETRA call 

in a new SwMI 

Figure 19 shows the information flow sequence for call restoration in the forward switching SwMI. 



MSC Call_restoration_forward_switching_SwMI 



Old SwMI CCAp 

I FE1 I 



ISI gateway 



FE2 



Forward switching 
SwMI ISI gateway 

I FE? I 



Forward switch he 
SwMI CCAp 

I FET I 



ISI-IC -RESTORE 
PREPAREreqJnd 



ISI-IC-CALL RESTORE 
PREPARE_req_ind 



l3l-IC-RELEASE_recLind lSI-IC-RELEASE_reqJnd 

-* -^ 



; RELEASE_reqJnd; 



(REL EAS E_resp_co nf ) 



ISI-IC-CALL RESTORE 
PREPARE_req_ind 



ISI-IC-CALL 
RESTORE_req_ind 



ISI-IC-CALL 
RESTORE_req_ind 



Other end 
SwMI gateway 

I FE7 I 



Other end 
SwMI CCAp 

FE8 I 



ISI-IC-CALL 
RESTOREreqJnd 



Figure 19: Information flow sequence - call restoration of an established inter-TETRA call 

in the forward switching SwMI 
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Figure 20 shows the information flow sequence for call restoration in the other end SwMI. 



MSC Call restoration other end SwMI 






1 I 



Old SwMI CCAp 
I FE1 I 



ISI gateway 
FE2 



ISI-IC-CALL RESTORE 
PREPAREreqJnd 



ISI-IC-RELEASE_reqJnd 



New/other end SwMI 
ISI gateway 

I FE2' I 



New/other end 
SwMI CCAp 

I Fet I 



ISI-IC-CALL RESTORE 
PREPAREreqJnd 



ISI-IC-RELEASE_reqJnd 



T 



RELEASE_reqJnd 



RELEASE resp_conf I 



ISI-IC-CALL RESTORE 
PREPARE req ind 



ISI-IC-RELEASE_reqJnd 



Figure 20: Information flow sequence - call restoration of an established inter-TETRA call 

in the other end SwMI 

Figure 21 shows the information flow sequence for call restoration of an intra-TETRA call in another SwMI. 



MSC Call restoration intra TETRA call 



i\ 

14 



I 



Old SwMI CCAp 
I FE1 I 



ISI outgoing 
gateway 

FE2 



ISI incoming 
gateway 

FE2^ 



New SwMI CCAp 
I Fi? I 



ISI-IC-CALL RESTORE 
PREPAREreqJnd 



1 SETUP_reqJnd I 



ISI-IC-CALL 
RESTORE_reqJnd 



ISI-IC-CALL RESTORE 
PREPAREreqJnd 



I SETUP_resp_oonf 



ISI-IC-CALL 
RESTORE_reqJnd 



ISI-IC-CALL RESTORE 
PREPAREreqJnd 



ISI-IC-CALL 
RESTORE_reqJnd 



Figure 21 : Information flow sequence - call restoration of an established intra-TETRA call 
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5.2.1.10 Call clearing 

Figure 22 shows the information flow sequence when a call is cleared by its calling user. A symmetrical sequence 
applies when a call is cleared by its called user. 



MSC CalLclearing 






I 



Originating 
SwIVII CCAp 

FE1 



ISI outgoing gateway 
I FE2 I 



Transit CC 



ISI incoming 
gateway 

FE7 



Terminating 
SwMI CCAp 

FE8 



ISI-IC-RELEASE_reqJnd 



-^i 



ISI-IC-RELEASE_reqJnd 



RELEASE_reqJnd I 



rRELEASE_resp_confl 



^ 



RELEASE_resp_conf 



ISI-IC-RELEASE_reqJnd 



Figure 22: Information flow sequence - call clearing 

5.2.2 Definition of information flows 

In the tables listing the service elements in information flows, the column headed "Request" indicates which of these 
service elements are mandatory (M) and which are optional (O) in a request/indication information flow, and the 
column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a 
response/confirmation information flow. 

5.2.2.1 CALL RESTORE 

CALL RESTORE is an unconfirmed information flow across the following relationships: 

rk from FEl ' to FE2', rj from FE2' to FE2, rg from FE2 to FE7 and rh from FE7 to FES, if the user restoring the 
call is the calling user; 

rk from FES' to FE7' rl from FE7' to FE7, rg from FE7 to FE2 and ra from FE2 to FEl, if the user restoring the 
call is the connected user. 

It informs the SwMI where the user was previously registered that it is not going to be anymore an end SwMI and that it 
should take the actions specified for call restoration (e.g. in the general case: joining the leg with the new SwMI and the 
existing ISI call path with the other end SwMI). 

It also informs the SwMI at the other end about the call restoration, with possible call modifications proposed by the 
new SwMI. 

Table 3 lists the service elements within the CALL RESTORE information flow. 
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Table 3: Contents of CALL RESTORE 



Service element 


Request 


NewSwMI MNI 


M 


Simplex/duplex selection 


M 


Call priority 


M 


Basic service information 


M 


Transmission request permission 


(see note) 


Transmission grant 


(see note) 


Call status 





NOTE: Mandatory if this information flow is sent by FE1 ' (corresponding to controlling SwMI). Not to be 
included if this information flow is sent by FE8'. 



5.2.2.2 CALL RESTORE PREPARE 

CALL RESTORE PREPARE is an unconfirmed information flow across the following relationships: 

ra from FEl to FE2, rj from FE2 to FE2' and rk from FE2' to FEl', if the user restoring the call is the calling 
user; 

rh from FES to FE7, rl from FE7 to FE7' and rk from FE7' to FES', if the user restoring the call is the connected 
user. 

It informs the SwMl where the user is now registered to prepare for call restoration. 

NOTE: Although formally CALL RESTORE PREPARE is an unconfirmed information flow, it is actually 
confirmed when the call restoration has been successful: 

by the CALL RESTORE request/indication information flow, in the general case where the call 
restoration takes place in a SwMI different from those on the path of the call (i.e. FEl' is not 
collocated with FES nor located in a SwMI through which the call has been forward switched, or FES' 
is not collocated with FEl nor located in a SwMI through which the call has been forward switched); 

by the PISN basic call RELEASE request/indication information flow in the specific cases where the 
call restoration takes place in a SwMI on the path of the call, including the end SwMIs (originating 
and terminating SwMIs). 

The case where the call restoration has not been successful can only be detected by the expiry of a timer 
for the reception of the information flows mentioned above in the cases of successful call restoration. 

Table 4 lists the service elements within the CALL RESTORE PREPARE information flow. 

Table 4: Contents of CALL RESTORE PREPARE information flow 



Service element 


Request 


Other end SwMI MNI 


M 


Basic service information 


M 


Speech services supported 


(note 1 ) 


Security level at calling user air interface 


M 


Call priority 


M 


Call time-out 


M 


Simplex/duplex selection 


M 


Transmission request permission 


(note 2) 


Transmission grant 


(note 2) 


NOTE 1 : May be sent if the service requested (in the service element basic service information) is a speech 

service. 
NOTE 2: Mandatory if this information flow is sent by FE1 (corresponding to controlling SwMI). Not to be 

included if this information flow is sent by FE8. 
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5.2.2.3 



CHARACTERISTIC CHANGE 



CHARACTERISTIC CHANGE is an unconfirmed information flow across relationship rh from FES to FE7, rg from 
FE7 to FE2 and ra from FE2 to FEl. It is an advance indication to the originating one that the terminating SwMI wants 
to change some of the characteristics requested in the SETUP information flow (e.g. basic service not supported, or 
simply call set-up time-out extension). The sending of this information flow by FES is optional. 

Table 5 lists the service elements within the CHARACTERISTIC CHANGE information flow. 

Table 5: Contents of CHARACTERISTIC CHANGE 



Service element 


Request 


Call time-out in set-up pliase 





Simplex/duplex selection 





Call status 





Basic service information 


(note) 


NOTE: Only if different from requested. 



5.2.2.4 COMPLETE 

COMPLETE is an information flow: 

across relationship ra, between FEl and FE2; 

across relationship rh, between FE7 and FES; 

and: 

if the called user is registered in SwMI B, depending on whether or not FE4 is collocated with FEl, across 
relationship rf, between FE6 and FE7, or across relationship re, between FE2 and FE4; 

if the called user is registered in SwMI C (after having migrated): 

if the call is forward switched, across relationships re, between FE2 and FE4, re, between FE4 and FE6, 
and rf, between FE6 and FE7; 

if the call is re-routed, across relationship rf, between FE6 and FE7. 

If the call is established using on/off hook signalling, COMPLETE is a confirmed information flow, as shown in 
figure 9. It is an unconfirmed information flow if the call is established using direct set-up signalling, as shown in 
figure 10. 

Table 6 lists the service elements within the COMPLETE information flow when it is a confirmed flow, and table 7 lists 
them when it is an unconfirmed flow. 

Table 6: Contents of confirmed COMPLETE information flow 



Service element 


Request 


Response 


Terminating SwIVll MNI 


M 


- 


Call amalgamation 





- 


Call time-out 


M 


M 


Connected party identity 


M 


- 


Simplex/duplex selection 


M 


- 


Transmission request permission 


- 


M 


Transmission grant 


- 


M 



Table 7: Contents of unconfirmed COIVIPLETE information flow 



Service element 


Request 


Call time-out 


M 


Transmission request permission 


M 


Transmission grant 


M 
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5.2.2.5 



INFORM 1 



INFORM 1 is a confirmed information flow across rb from FE2 to FE3, and across rd from FE4 to FES. It is used by 
FE2 to get information on how to route the invoked ANF-ISIIC to SwMI B, or in case of re-routing, to SwMI C, and by 
FE4, to get information on how to route the invoked ANF-ISIIC to SwMI C in case of forward switching. 

Table 8 lists the service elements within the INFORM 1 information flow. 

Table 8: Contents of INFORM 1 



Service element 


Request 


Response 


Routing information towards FE4 or FE7 


- 


M 


Call priority 


M 


(note) 


NOTE: The routing information provided (by FES or FES) in response to the request shall take into account 
the call priority if SS-PC or SS-PPC have been invoked. 



5.2.2.6 



INFORM 2 



INFORM 2 is a confirmed information flow across rd from FE4 to FES. It is used by FE4 to know the SwMI where the 
called user is registered (i.e. in SwMI B, or in SwMI C), and to get information on the SS-BIC, SS-CAD or SS-CF 
possibly activated. 

There are no elements in the INFORM 2 request/indication information flow. Table 9 lists the service elements within 
the INFORM 2 response/confirmation information flow. 

Table 9: Contents of INFORM 2 response/confirmation information flow 



Service element 


Response 


Identity of the SwIVII where the called user is registered 


M 


SS-BIC activation 


M 


SS-BIC "definition" 


C (note) 


SS-CAD activation 


M 


SS-CAD "definition" 


C (note) 


SS-CF activation 


M 


SS-CF "definition" 


C (note) 


NOTE: Mandatory if the corresponding supplementary service has been activated. 



5.2.2.7 



INFORM 3 



INFORM 3 is a confirmed information flow across rb from FE2 to FE3. It is used by FE2 in the case where SwMI C 
coincides with SwMI A, to get information on the local SS-BIC, SS-CAD or SS-CF possibly activated. 

There are no elements in the INFORM 3 request/indication information flow. Table 10 lists the service elements within 
the INFORM 3 response/confirmation information flow. 

Table 10: Contents of INFORM 3 response/confirmation information flow 



Service element 


Response 


Local SS-BIC activation 


M 


Local SS-BIC "definition" 


C (note) 


Local SS-CAD activation 


M 


Local SS-CAD "definition" 


C (note) 


Local SS-CF activation 


M 


Local SS-CF "definition" 


C (note) 


NOTE: Mandatory if the corresponding (local) supplementary service has been activated. 
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5.2.2.8 



MIGRATION 



MIGRATION is an information flow across relationship re from FE4 to FE2. The MIGRATION request information 
flow is sent by FE4 when the called user is registered in SwMI C (i.e. the home SwMI of the called user is SwMI B and 
this user has migrated). It is a confirmed information flow unless FE2 has informed in advance FE4 that the call has to 
be forward switched when the called user has migrated (in another SwMI than the originating one). The MIGRATION 
information flow shall not be sent when SwMI C coincides with SwMI A. 

NOTE: It is then replaced by the TROMBONE information flow - see hereafter. 

Table 1 1 lists the service elements within the MIGRATION information flow when it is a confirmed flow, and table 12 
lists them when it is an unconfirmed flow. 

Table 1 1 : Contents of confirmed MIGRATION information flow 



Service element 


Request 


Confirm 


Identity of the SwMI where the called user is registered 


M 


- 


Forward switching (note) 


M 


M 


NOTE: In the request information flow, this information element indicates whether forward 
switching is supported or not (or possibly if FE4 refuses that forward switching takes 
place). In the response information flow, it indicates whether FE2 wants that the call be 
forward switched or not, i.e. the call is going to re-routed. In the latter case, this 
information flow shall be sent to FE4 with the PISN RELEASE request/indication 
information flow. 



Table 12: Content of unconfirmed MIGRATION information flow 



Service element 



Request 



Identity of the SwIVII where the called user is registered 



M 



5.2.2.9 



MODIFY 



MODIFY is a confirmed information flow across relationships ra, rg and rh, from FEl to FES via FE2 and FE7 and 
vice-versa. The MODIFY request/indication information flow sends a request to modify the existing basic service into 
another one, and/or to change from duplex to half-duplex, or vice-versa, and/or to change the call duration. The 
MODIFY response/confirmation information flow indicates the response to this request. FE2 or FE7 may reject such 
request if the ISI gateways in which they are located do not support the user information 8 kbit/s encoding entailed by a 
request to change the basic service. 

Table 13 lists the service elements within the MODIFY information flow. 

Table 13: Contents of MODIFY 



Service element 


Request 


Confirm 


Basic service information: 






Circuit mode service 








Communication type 








Data call capacity 


C (note) 


C (note) 


Data service 


C (note) 


C (note) 


Encryption flag 








Speech service 


C (note) 


C (note) 


Call time-out 








Simplex/duplex selection 








NOTE: Depending on the value of circuit mode service. 



5.2.2.10 



RELEASE 



RELEASE is an unconfirmed information flow across relationships ra, rh, re, rf and rg. It shall be sent to clear the call 
(together with the invoked ANF-ISIIC). 
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NOTE: As recalled in the note to figure 15, the PISN RELEASE information flow is a confirmed information 

flow on all PISN basic call relationships which support relationships re, rf and rg. But this does not make 
the ANF-ISIIC RELEASE information flow a confirmed one. 

Table 14 indicates the only service element within the RELEASE information flow. 

Table 14: Contents of RELEASE 



Service element 


Request 


Disconnect cause 


M 



5.2.2.11 SETUP 

SETUP is a confirmed information flow: 

across relationship ra from FEl to FE2; 

across relationship rh from FE7 to FES; 

and: 

if the called user is registered in SwMI B, depending on whether or not FE4 is collocated with FEl, across 
relationship rf from FE6 to FE7, or across relationship re from FE2 to FE4; 

if the called user is registered in SwMI C (after having migrated): 

- if the call is forward switched, across relationships re from FE2 to FE4, re from FE4 to FE6, and rf from 
FE6 to FE7; 

- if the call is re-routed, across relationship rf from FE6 to FE7. 

The SETUP request/indication information flow enables the TETRA call to be set-up by the originating SwMI up to the 
terminating SwMI. The SETUP response/confirmation information flow is sent by the terminating SwMI upon the first 
response of the called user, i.e.: 

in the case of on/off hook signalling, this first response will generate a U-ALERT air interface PDU. The (ISI- 
IC-)SETUP response/confirmation information flow shall then be carried together with the PISN REPORT 
request/indication information flow(s). The TNCC ALERT primitive may be sent to the calling user by SwMI A 
call control application; 

while in the case of direct set-up signalling, this first response will generate a U-CONNECT air interface PDU. 
The ISI-IC-SETUP response/confirmation information flow shall then be carried together with the PISN SETUP 
response/confirmation information flow. 

Table 15 lists the service elements within the SETUP information flows. 



£75/ 



61 



ETSI TS 100 392-3-2 V1.1.1 (2000-10) 



Table 15: Contents of SETUP 



Service element 


Request 


Confirm 


Originating SwIVII IVINI 


M 


- 


Routing method choice 





- 


Terminating SwMI MNI 


- 


(note 2) 


Call time-out, set-up phase 


M 


(note 3) 


Basic service information: 


- 


- 


Circuit mode service 


M 


(note 2) 


Communication type 


M 


(note 2) 


Data call capacity 


C(note 1) 


C(note 1) 


Data service 


C{note 1) 


C(note 1) 


Encryption flag 


M 


(note 2) 


Speech service 


C{note 1) 


C(note 1) 


Speech services supported 


(note 4) 


- 


Security level at calling user air interface 


M 


M 


Call priority 


M 


(note 2) 


Call amalgamation 


- 


(note 2) 


Call time-out 


M 


(note 2) 


Called/Connected party number 


M 


(note 2) 


Calling party number 


M 


- 


Hook method selection 


M 


M (note 5) 


Request to transmit/send data 


M 


- 


Simplex/duplex selection 


M 


M 


Transmission request permission 


M 


- 


Transmission grant 


M 


- 


Call queued 


- 


(note 6) 


NOTE 1 : Depending on the value of circuit mode service. 

NOTE 2: Mandatory in the case of direct set-up signalling. Not to be included in the case of on/off hook 

signalling. 
NOTE 3: IVIandatory in the case of on/off hook signalling. Not to be included in the case of direct set-up 

signalling. 
NOTE 4: IVIay be sent if the service requested is a speech service. 
NOTE 5: IVIandatory to indicate the actual choice made by the called user: in other words, it indicates whether the 

called user has accepted or changed the hook selection method requested. 
NOTE 6: Optional in the case of on/off hook signalling. Not to be included in the case of direct set-up signalling. 



NOTE: The service element call priority has been included in table 15 for the purpose of alignment with the 

definition of the TNCC-SETUP primitive in table 48 of EN 300 392-2 [1]. From a formal point of view it 
should not have been included in that table because it is not needed by ANF-ISIIC basic call: it is needed 
only for the interaction between the invoked ANF-ISIIC and the supplementary services SS-PC and SS- 
PPC. 



5.2.2.12 



SETUP PROLONGATION 



SETUP PROLONGATION is an unconfirmed information flow across relationships ra, rg and rh, from FEl to FES via 
FE2 and FE7 and vice-versa, to request a set-up time-out extension. Table 16 shows the service element within the 
SETUP PROLONGATION information flow. 

Table 16: Content of SETUP PROLONGATION 



Service element 


Request 


Call time-out, set-up phase 


M 



5.2.2.13 



TROMBONE 



TROMBONE shall be a confirmed information flow across relationship re from FE4 to FE2. The TROMBONE request 
information flow is sent by FE4 when FE4 has identified that SwMI C coincides with SwMI A. The TROMBONE 
response is then a confirmation that the invoked ANF-ISIIC FE4 may be cleared. 

Table 17 lists the service elements within the TROMBONE request/indication information flow (sent by FE4). There 
are no service elements within the TROMBONE response/confirmation information flow (sent by FE2). 
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Table 17: Contents of TROMBONE request/indication information flow 



Service element 


Request 


Terminating and originating SwIVIIs coinciding 


M 


Results of possible SS-BIC and SS-CAD (for incoming calls) 


M (notes 1 and 2) 


SS-CF invoked 


M 


SS-CF "definition" 


C (note 3) 


NOTE 1 : If none of these supplementary services has been activated, this shall be indicated. 

NOTE 2: The case where the result would be that the call is not authorized by SS-CAD is excluded, since it 

would not result in the sending of a TROMBONE request information flow, but in the ANF-ISIIC call 

establishment being rejected. 
NOTE 3: IVIandatory if SS-CF has been invoked. 



NOTE: According to the current specification of the call forwarding supplementary services (see 

EN 300 392-12-4 [9]), the only call forwarding supplementary services which may be invoked in the 
home SwMI of the SS-CF served user when that user has migrated (in the specific case where 
TROMBONE is sent, that user has migrated into SwMI A) are SS-CFU or SS-CFNRc. 

5.2.2.14 TX-CEASED 

TX-CEASED is an unconfirmed information flow across ri from FES to FEl to indicate that transmission from the 
called user has ceased. 

Table 18 lists the service elements within the TX-CEASED information flow. 

Table 18: Contents of TX-CEASED 



Service element 


Request 


Transmission request permission 


M 


Notification indicator 





Proprietary 






5.2.2.15 



TX-CONTINUE 1 



TX-CONTINUE 1 is an unconfirmed information flow across ri from FEl to FES to indicate that transmission has 
resumed. 

Table 19 lists the service elements within the TX-CONTINUE 1 information flow. 

Table 19: Contents of TX-CONTINUE 1 



Service element 


Request 


Continue 


M 


Transmission request permission 


M 


Notification indicator 





Proprietary 






5.2.2.16 



TX-CONTINUE 2 



TX-CONTINUE 2 is an unconfirmed information flow across ri from FES to FEl to indicate that transmission may 
resume. 

Table 20 lists the service elements within the TX-CONTINUE 2 information flow. 

Table 20: Contents of TX-CONTINUE 2 



Service element 


Request 


Notification indicator 





Proprietary 
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5.2.2.17 



TX-DEMAND 



TX-DEMAND is an unconfirmed information flow across ri from FES to FEl. It is a request from the terminating 
SwMI to the originating/controlling SwMI for transmission grant (following the corresponding request received from 
the called user). 

Table 21 lists the service elements within the TX-DEMAND information flow. 

Table 21 : Contents of TX-DEMAND 



Service element 


Request 


Transmission request permission 


M 


Encryption control 


M 


Notification indicator 





Proprietary 






5.2.2.18 



TX-G RANTED 



TX-GRANTED is an unconfirmed information flow across ri from FEl to FES. It is an indication to the terminating 
SwMI from the originating/controlling SwMI that permission to transmit has been granted to either the calling or the 
called user. 

Table 22 lists the service elements within the TX-GRANTED information flow. 

Table 22: Contents of TX-GRANTED 



Service element 


Request 


Transmission grant 


M 


Transmission request permission 


M 


Encryption control 


M 


Notification indicator 





Proprietary 






5.2.2.19 



TX-INTERRUPT 



TX-INTERRUPT is an unconfirmed information flow across ri from FEl to FES. It is an indication to the terminating 
SwMI from the originating/controlling SwMI that permission to transmit has been withdrawn. 

Table 23 lists the service elements within the TX-INTERRUPT information flow. 

Table 23: Contents of TX-INTERRUPT 



Service element 


Request 


Transmission grant 


M 


Transmission request permission 


M 


Encryption control 


M 


Notification indicator 





Proprietary 






5.2.2.20 



TX-WAIT 



TX-WAIT is an unconfirmed information flow across ri from FEl to FES or from FES to FEl to indicate that 
transmission has been interrupted. 

Table 24 lists the service elements within the TX-WAIT information flow. 
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Table 24: Contents of TX-WAIT 



Service element 


Request 


Transmission request permission 


M 


Notification indicator 





Proprietary 






5.2.3 Relationship of information flows to basic call information flows 

The (TETRA ANF-ISIIC) SETUP request/indication information flows across relationships re and rf shall be sent in 
conjunction with the PISN basic call r2_setup request/indication information flows sent to initiate the establishment of 
the necessary PISN call. 

The (TETRA ANF-ISIIC) SETUP response/confirmation information flows across relationships rf and re shall be sent 
in conjunction with either the PISN basic call r2_report request/indication information flows if the called user uses 
on/off hook signalling, or the PISN basic call r2_setup response/confirmation information flows if the called user uses 
direct set-up signalling. 

The (TETRA ANF-ISIIC) COMPLETE request/indication information flow across relationships re and rf shall be sent 
in conjunction with the PISN basic call r2_setup response/confirmation if the called user uses on/off hook signalling. 

The (TETRA ANF-ISIIC) RELEASE request/indication information flows across relationships re, rf and rg shall be 
sent in conjunction with the PISN basic call r2_release request/indication information flows. 

None of the other (ANF-ISIIC) information flows are related to any PISN basic call information flows. 

5.3 Functional entity actions 

The FE actions in the figures in subclause 5.2.1 shall fulfil the requirements set to the functional entities. 

5.4 Allocation of functional entities to physical 
equipment/SwMIs 

The different scenarios for the allocation of FEs to physical equipment/SwMIs is shown in table 25. 

Scenario 1 corresponds to the case where the called user is registered in its home SwMI, this SwMI being different from 
the originating SwMI. 

Scenarios 2 and 3 both correspond to the case where the called user has migrated to a third SwMI (SwMI C), its home 
SwMI being different from the originating SwMI. In scenario 2, the call is forward switched (in SwMI B); while in 
scenario 3, it is re-routed (in SwMI A). 

Scenario 4 is a special case of scenario 3 when SwMI C coincides with SwMI A: the invoked ANF-ISIIC shall then be 
cleared and as stated in subclause 4.2.3.2, SwMI A call control application shall establish the call as an intra-TETRA 
call. 

Scenario 5 corresponds to the case where the called user has migrated, its home SwMI being the originating SwMI. 

NOTE: In scenario 5, there are only two SwMIs. In line with subclause 3.1, on definitions, the second SwMI has 
been called SwMI B. 
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Table 25: Scenarios for the allocation of FEs to physical equipment/SwMIs 





FEI/Originating 
SwMI CCAp 


FE2/0riginating 
SwIVII ISI gateway 


FE3/Client of 

originating SwMI 

databases 


FE4/hSwlVII 
migration 
handling 


FE5/Client of 

hSwMI 

databases 


FE6/migration routing 


FE7/Terminating 
SwMI ISI gateway 


FE7/Terminatin 
g SwMI CCAp 


Scenario 1 


Any SwMI CCAp 
(SwMI A CCAp) 


SwMI A ISI outgoing 
gateway 


SwMI A routing table 
client 


SwMIB 


SwMI B 


- 


SwMI B ISI incoming 
gateway 


SwMI B CCAp 


Scenario 2 


Any SwMI CCAp 
(SwMI A CCAp) 


SwMI A ISI outgoing 
gateway 


SwMI A routing table 
client 


SwMIB 


SwMI B 


SwMI B ISI forward 
switching entity 


SwMI C ISI incoming 
gateway 


SwMI C CCAp 


Scenario 3 


Any SwMI CCAp 
(SwMI A CCAp) 


SwMI A ISI outgoing 
gateway 


SwMI A routing table 
client 


SwMIB 


SwMIB 


SwMI A ISI re-routing 
entity 


SwMI C ISI incoming 
gateway 


SwMI C CCAp 


Scenario 4 


Any SwMI CCAp 
(SwMI A CCAp) 


SwMI A ISI outgoing 
gateway 


SwMI A routing table 
client 


SwMIB 


SwMI B 


SwMI A CCAp 






Scenario 5 


Any SwMI CCAp 
(SwMI A CCAp) 


SwMI A ISI outgoing 
gateway 


SwMI A routing table 
client 


(note) 


(note) 


SwMI A ISI outgoing 
gateway 


SwMI B ISI incoming 
gateway 


SwMI B CCAp 


NOTE: In scenario 5, FE4 and FE 5 are not ANF-ISIIC FEs: the corresponding functions are ensured by SwMI A call control application. 
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ANF-ISIIC stage 3 specification 



6.1 ANF-ISIIC description 

See clause 4. 

6.2 ANF-ISIIC operational requirements 

The requirements specific for each type of SwMI are stated below. In addition, each SwMI shall comply with the 
requirements stated in: 

annex ZA of ISO/IEC 1 1572 [16], for the support of the PSSl message segmentation/re-assembly procedures; 
and 

- subclause 8.4 of ETS 300 392-3-1 [2], for the support of the ROSE protocol. 

6.2.1 Requirements on the originating SwMI 

The originating SwMI entity which operates an invoked ANF-ISIIC shall support call establishment and call clearing 
procedures for an originating PINX, as specified in ISO/IEC 1 1572 [16]. In addition, the following rules shall apply for 
the contents of some information elements in the SETUP message: 

the sending complete information element shall be included when the called party number is complete; 

NOTE 1 : Although it might be expected that the called party number shall be sent en-bloc, the use of (PISN) 

overlap sending (see subclauses 10.1.1, 10.1.3 and 10.1.4 of ISO/IEC 11572 [16] for the corresponding 
descriptions) is not prevented by the present document. 

the bearer capability information element shall be encoded with information transfer capability code equal to 
unrestricted digital information, and an information transfer rate code equal to 64 kbit/s; 

NOTE 2: As an option, when this shall have been standardized (either in ISO/IEC 1 1572 [16], or in the 

corresponding ETS), the information transfer rate code might be equal to either 8 kbit/s or multi-rate (8 
kbit/s base rate). For the latter, the multiplier code would be chosen from 2 to 4. This would correspond to 
the use of an N x 8 kbit/s bearer service. 

no progress indicator information element shall be included; 

the calling party number information element shall be included. The corresponding number shall be some PISN 
number identifying the calling SwMI, or one of its entities. Thus its numbering plan identification code shall be 
equal to either private numbering plan or unknown. No presentation or screening indicators shall be included 
(i.e. the calling party information element shall not include octet 3a); 

NOTE 3: The type of number code associated to the former will be as defined in table 26 of ISO/IEC 1 1572 [16]. 

NOTE 4: Putting an identifier of the calling SwMI in the calling party number information element is not in line 
with the requirement in subclause 10.5.1 of ISO/IEC 11572 [16] that the number included in this 
information element shall be that of the calling (TETRA) user. 

The reasons for this are first that the calling party number information element is not needed for PISN 
signalling, and second that any TETRA control entity in a SwMI on the call path (i.e. the terminating 
SwMI or when different from this SwMI, the called SwMI) needing to know the calling party number 
will get it as part of the complementary TETRA set-up information (see table 26). 

no calling party sub-address information element shall be included; 

the number included in the called party number information element shall be some PISN number identifying the 
called SwMI, or one of its entities. Thus its numbering plan identification code shall be equal to either private 
numbering plan or unknown; 
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NOTE 5: The type of number code associated to the former will be as defined in table 26 of ISO/IEC 1 1572 [16]. 

no called party sub-address information element shall be included; 

no lower layer or high layer compatibility information elements shall be included; and 

the transit counter information element, defined in EN 300 172 [6]. 

Generic procedures for the call related control of supplementary services, specified in ISO/IEC 1 1582 [18] for an End 
PINX, shall apply for sending or receiving TETRA specific messages or TETRA information complementary to PS SI 
basic call messages. Such messages or complementary information shall be encoded as ROSE operation Invoke APDUs 
in facility information elements. Notably complementary TETRA set-up information shall be sent in a facility 
information element in the SETUP message. 

NOTE 6: No support of any generic procedure for the call independent control (connection oriented) of 
supplementary services is required since the ANF-ISIIC protocol is only call related. 

6.2.2 Requirements on the terminating SwMI 

The terminating SwMI entity which operates an invoked ANF-ISIIC shall support call establishment and call clearing 
procedures for a terminating PINX, as specified in ISO/IEC 1 1572 [16]. In addition, the following rules shall apply for 
the contents of the connected number and connected sub-address information elements in the CONNECT message: 

the connected number information element shall be included. The corresponding number shall be some PISN 
number identifying the terminating SwMI, or one of its entities. Thus its numbering plan identification code shall 
be equal to either private numbering plan or unknown. No presentation or screening indicators shall be included 
(i.e. the called party information element shall not include octet 3a); 

NOTE 1: The type of number code associated to the former will be as defined in table 26 of ISO/IEC 11572 [16]. 

NOTE 2: Putting an identifier of the terminating SwMI in the connected number information element is not in line 
with the requirement in subclause 10.6.4 of ISO/IEC 1 1572 [16] that the number included in this 
information element shall be that of the connected (TETRA) user. 

The reasons for this are first that the connected number is not needed for PSSl signalling and second that 
any TETRA control entity in a SwMI on the call path (i.e. the originating SwMI or when different from 
the terminating SwMI, the called SwMI) needing to know the connected party number will get it as part 
of the complementary TETRA set-up response information (see table 31). 

no connected party sub-address information element shall be included. 

No progress indicator should be sent in the ALERTING or CONNECT messages, since no tones or announcements will 
be sent, and it shall not be considered that an interworking situation occurs for inter-TETRA individual calls. And for 
the same reason, no PROGRESS message should be sent. 

Generic procedures for the call related control of supplementary services, specified in ISO/IEC 1 1582 [18] for an End 
PINX, shall apply for receiving or sending TETRA specific messages or TETRA information complementary to PSSl 
basic call messages. Such messages or complementary information shall be encoded as ROSE operation Invoke APDUs 
in facility information elements, notably in the ALERTING or CONNECT messages. 

6.2.3 Requirements on a called SwMI when it is different from the 
terminating SwMI 

When the called user is not registered in the called SwMI, this SwMI shall redirect the call. Its redirecting entity which 
operates an invoked ANF-ISIIC shall support call establishment and call clearing procedures for the incoming side of an 
inter-PINX Hnk, as specified in ISO/IEC 11572 [16]. 

Generic procedures for the call related control of supplementary services, specified in ISO/IEC 1 1582 [18] for an End 
PINX, shall apply. 



£75/ 



68 ETSI TS 100 392-3-2 V1.1.1 (2000-10) 



6.2.4 Requirements on a routing SwMI 



The routing SwMI entity which operates an invoked ANF-ISIIC shall support call establishment and call clearing 
procedures for the outgoing side of an inter-PINX link, as specified in ISO/IEC 1 1572 [16]. The number included in the 
calling party number information element of its PSSl SETUP message shall be the same PISN number as in the PSSl 
SETUP message sent by the originating SwMI (see subclause 6.2.1). No presentation or screening indicators shall be 
included (i.e. the calling party information element shall not include octet 3a). The number included in the called party 
number information element shall be some PISN number identifying the terminating SwMI, or one of its entities. Thus 
its numbering plan identification code shall be equal to either private numbering plan or unknown. 

NOTE 1: The type of number code associated to the former will be as defined in table 26 of ISO/IEC 11572 [16]. 

In addition, after having sent this SETUP message, except if the routing SwMI is also the originating SwMI (case of 
re-routing), the routing SwMI shall support the call establishment and call clearing procedures for a transit PINX. 

NOTE 2: In the case of forward switching, the incoming side procedures of a transit for receiving the SETUP 
message are ensured by the called SwMI. They are not needed in the case of re-routing. 

Generic procedures for the call related control of supplementary services, specified in ISO/IEC 1 1582 [18] for an End 
PINX, shall apply. 

6.2.5 Requirements on a SwMI witin PSTN/ISDN/PISN incoming gateway 

The SwMI entity which operates an invoked ANF-ISIIC for extending an external individual call to a TETRA called 
user over the ISI shall support call establishment and call clearing procedures for an incoming gateway PINX, as 
specified in ISO/IEC 1 1572 [16]. In addition, the following rules shall apply for the contents of some information 
elements in the SETUP message: 

the sending complete information element shall be included when the called party number is complete; 

NOTE 1: Although, it might be expected that the called party number shall be sent en-bloc, the use of (QSIG) 

overlap sending (see subclauses 10.1.1, 10.1.3 and 10.1.4 of ISO/IEC 11572 [16] for the corresponding 
descriptions) is not prevented by the present document. 

the bearer capability information element shall be encoded with information transfer capability code equal to 
unrestricted digital information, and an information transfer rate code equal to 64 kbit/s; 

NOTE 2: As an option, when this shall have been standardized (either in ISO/IEC 1 1572 [16], or in the 

corresponding ETS), the information transfer rate code might be equal to either 8 kbit/s or multi-rate (8 
kbit/s base rate). For the latter, the multiplier code would be chosen from 2 to 4. This would correspond to 
the use of an N x 8 kbit/s bearer service. 

one, two or three progress indicator information elements shall be included, depending on the number of 
progress description numbers to send, with: 

a location code equal to transit network; and 

- for a PSTN call: 

a CCITT progress description number 1 "call is not end-to-end ISDN"; 

an ISO/IEC progress description number 16 "interworking with a public network"; and 

if the PSTN access line interface used at the gateway cannot deliver a release signal (e.g. standard 
PSTN extension line - with no battery reversal signal), an ISO/IEC progress description number 17 
"interworking with a network unable to supply a release signal" (or an ISO/IEC progress description 
number 18 or 19, depending on whether it can supply a release signal after answer, but not before, or 
before answer, but not after); 

for a public ISDN call: an ISO/IEC progress description number 16 "interworking with a public ISDN"; 



for a PISN call: an ECMA progress description number 20 "interworking with a another private network"; 
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the calling party number information element shall be included. The corresponding number shall be some PISN 
number identifying the gateway SwMI, or one of its entities. Thus its numbering plan identification code shall be 
equal to either private numbering plan or unknown. No presentation or screening indicators shall be included 
(i.e. the calling party information element shall not include octet 3a); 

NOTE 3: The type of number code associated to the former will be as defined in table 26 of ISO/IEC 1 1572 [16]. 

NOTE 4: Putting an identifier of the calling SwMI in the calling party number information element is not in line 
with the requirement in subclause 10.7.1 of ISO/IEC 11572 [16] that the number included in this 
information element shall be the calling party number received from PSTN, public ISDN or PISN, if any. 

The reasons for this are the same as those given in note 4 of subclause 6.2.1. 

no calling party sub-address information element shall be included; 

the number included in the called party number information element shall be some PISN number identifying the 
called SwMI, or one of its entities. Thus its numbering plan identification code shall be equal to either private 
numbering plan or unknown; 

NOTE 5: The type of number code associated to the former will be as defined in table 26 of ISO/IEC 1 1572 [16]. 

no called party sub-address information element shall be included; 

no lower layer or high layer compatibility information elements shall be included; and 

the transit counter information element, defined in EN 300 172 [6]. 

Generic procedures for the call related control of supplementary services, specified in ISO/IEC 1 1582 [18] for an End 
PINX, shall apply for sending or receiving TETRA specific messages or TETRA information complementary to PSSl 
basic call messages. Such messages or complementary information shall be encoded as ROSE operation Invoke APDUs 
in facility information elements. Notably complementary TETRA set-up information shall be sent in a facility 
information element in the SETUP message. 

6.2.6 Requirements on a SwMI with PSTN/ISDN/PISN outgoing gateways 

The SwMI entity which operates an invoked ANF-ISIIC for routing an external individual call from a TETRA called 
user over the ISI shall support call establishment and call clearing procedures for an outgoing gateway PINX, as 
specified in ISO/IEC 1 1572 [16]. In addition, the following rules shall apply for the contents of the called party sub- 
address information element in the SETUP message and for that of the connected number and connected sub-address 
information elements in the CONNECT message: 

the connected number information element shall be included in the CONNECT message. The corresponding 
number shall be some PISN number identifying the gateway SwMI, or one of its entities. Thus its numbering 
plan identification code shall be equal to either private numbering plan or unknown. No presentation or 
screening indicators shall be included (i.e. the called party information element shall not include octet 3a); 

NOTE 1: The type of number code associated to the former will be as defined in table 26 of ISO/IEC 11572 [16]. 

NOTE 2: Putting an identifier of the gateway SwMI in the connected number information element is not in line 
with the requirement in subclause 10.8.5 of ISO/IEC 11572 [16] that the connected number included in 
this information element shall be that received from PSTN, public ISDN or PISN, if any. 

The reasons for this are the same as those given in note 2 of subclause 6.2.2. 

no connected party sub-address information element shall be included in the CONNECT message. 

In addition, one, two or three progress indicator information elements shall be sent to the calling SwMI by the gateway 
SwMI in the appropriate PSSl message, to indicate interworking, depending on the number of progress description 
numbers, with: 

a location code equal to transit network; and 

- for a PSTN call: 

a CCITT progress description number 1 "call is not end-to-end ISDN"; 
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an ISO/IEC progress description number 16 "interworking with a public network"; 

and, if the PSTN access line interface used at the gateway cannot deliver a release signal (e.g. standard PSTN 
extension line-with no battery reversal signal), an ISO/IEC progress description number 17 "interworking 
with a network unable to supply a release signal" (or an ISO/IEC progress description number 18 or 19, 
depending on whether it can supply a release signal after answer, but not before, or before answer, but not 
after); 

for a public ISDN call: an ISO/IEC progress description number 16 "interworking with a public ISDN"; 

or 

for a PISN call: an ECMA progress description number 20 "interworking with a another private network". 

Generic procedures for the call related control of supplementary services, specified in ISO/IEC 1 1582 [18] for an End 
PINX, shall apply for receiving or sending TETRA specific messages or TETRA information complementary to PSSl 
basic call messages. Such messages or complementary information shall be encoded as ROSE operation Invoke APDUs 
in facility information elements, notably in the PSSl ALERTING and CONNECT messages. 



6.3 ANF-ISIIC coding requirements 



As already mentioned in subclause 6.2, TETRA specific messages or TETRA information complementary to PSSl 
basic call messages shall be sent using an Invoke APDU of the ROSE operation tetralsiMessage defined in table 10 of 
ETS 300 392-3-1 [2]. This table has been reproduced in the informative annex B. 

More precisely: 

the TETRA specific messages or TETRA information complementary to PSSl basic call messages shall be the 
TETRA PDUs defined in subclause 6.3.1; and 

those PDUs shall be included in the tetraMessage data element of the ROSE operation tetralsiMessage. 

The resulting ROSE APDU shall be sent in a facility information element in the relevant PSSl message (see 
ISO/IEC 11582 [18] clause 10). 

NOTE: Clearly, those PSSl messages will be call related. 

6.3.1 TETRA PDUs 

The TETRA PDUs referred to in the ASN. 1 definition in table 25 shall be encoded using the same rule as defined in 
annex E of EN 300 392-2 [1] (for TETRA air interface PDUs). 

NOTE 1 : As a general rule, the definition of those PDUs has been done on the basis of the corresponding air 
interface downstream messages. In other words, the sending SwMI is preparing the corresponding 
message to be sent by the other SwMI on its air interface. 

Thus generally those PDUs include the same information elements as air interface messages. However, 
no facility information elements are included in those PDUs since ANF-ISISS is used instead (see 
clauses 9 and 10 of EN 300 392-9 [5]). 

NOTE 2: Even when only one TETRA PDU type has been defined below for inclusion in a given PSSl message 
(e.g. in the ALERTING message), the information element PDU type has been included in this TETRA 
PDU. The main reason for this is to allow the possibility of defining in the future other TETRA PDU 
types in the same PSSl message. Additionally it might ease the processing of these PDUs by the 
destination SwMI call control application. 

The definitions of all possible TETRA PDUs, in the various PSSl messages, are given below. 
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6.3.1 .1 TETRA PDU giving complementary information in the PSS1 SETUP 

message sent by the originating or the incoming gateway SwMI 

The contents and the encoding of the TETRA PDU giving complementary information in the PSSl SETUP message 
sent by the originating or incoming gateway SwMI shall be as defined in table 26. 

Table 26: Contents of TETRA PDU in the PSSl SETUP message 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-SETUP 


Originating SwMI MNI 


24 


1 


ANF 


M 




Call has been forward switched 


1 


1 


ANF 


M 




Last Forwarding SwMI MNI 


24 




ANF 


C 


note 1 


Routing method choice 


3 


1 


ANF 


M 




SS-CF invocation counter 


5 


1 


SS 


M 




Call time-out, set-up phase 


3 


1 


CCAp 


M 




Call time-out 


4 


1 


CCAp 


M 




Hook method selection 


1 


1 


CCAp 


M 




Simplex/duplex selection 


1 


1 


CCAp 


M 




Basic service information 


8 


1 


CCAp 


M 




Speech service requested 


3 




CCAp 


C 


note 2 


Security level at calling user air interface 


2 


1 


MM 


M 


note 3 


Transmission grant 


2 


1 


CCAp 


M 




Transmission request permission 


1 


1 


CCAp 


M 




Call priority 


4 


1 


CCAp 


M 




Called/forwarded-to party SSI 


24 


1 


CCAp 


M 


note 4 


Called/forwarded-to party extension 


24 


1 


CCAp 


M 


notes 4 and 5 


Number of digits in called/forwarded-to external subscriber 
number 


5 


1 


CCAp 


M 


note 6 


Called/forwarded-to external subscriber number 


variable 




CCAp 


C 


note 7 


Calling party presentation indicator 


2 


1 


SS 


M 




Calling party SSI 


24 


1 


CCAp 


M 


notes 


Calling party extension 


24 


1 


CCAp 


M 


notes 


Number of digits in calling external subscriber number 


5 


1 


CCAp 


M 


note 9 


Calling external subscriber number 


variable 




CCAp 


C 


note 10 


MSISDN present as external subscriber number 


1 




CCAp 


C 


note 1 1 


Calling external subscriber number parameters 


9 




CCAp 


C 


note 1 1 


Call identified as fleet call 


1 


1 


CCAp 


M 




Calling party fleet number SSI 


24 




CCAp 


C 


note 1 2 


Called/forwarded-to party fleet number SSI 


24 




CCAp 


C 


note 1 2 


Override SS-CAD invocation 


1 


1 


SS 


M 


note 1 3 


Speech services supported 


8 


2 


CCAp 





note 1 4 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 







NOTE 1 : Conditional on the value of the information element ca 
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NOTE 8: In the case of an external incoming call, the calling party SSI and the calling party extension shall be 

those of the incoming gateway SwIVII. 
NOTE 9: Shall be equal to when no calling external subscriber number is present, or to N, N being the number of 

digits which the calling external subscriber number comprises. 
NOTE 10: The length in bits of this information element shall be equal to 4 x N, N being the number of digits in the 

calling external subscriber number (see note 9), i.e. this information element shall be conditional on the 

value of N. 
NOTE 1 1 : Conditional on the value of the information element number of digits in calling external subscriber number 

being different from 0. 
NOTE 12: Conditional on the value of the information element call identified as fleet call indicating that the call has 

been identified as being a fleet call. 
NOTE 13: See interaction between SS-CCBS and SS-CAD. 
NOTE 14: May be present only when the information element speech service requested is present (see note 2). 



NOTE 1: Compared to the definition of the D-SETUP air interface downhnk PDU in subclause 14.7.2 of 
EN 300 392-2 [1], the following information elements have been deleted: 

calling type identifier, since it is always TETRA subscriber identity (actually ITSI); 

temporary address, because that information element is used only for group calls (and in any case not 
over the ISI); 

- facihty, since ANF-ISISS is used instead (see clauses 9 and 10 of EN 300 392-9 [5]). 
In addition the following information elements have been added: 

- originating SwMI MNI; 

call has been forward switched; 

- last forwarding SWMI MNI; 
routing method choice; 
forwarding counter; 

call time-out, set-up phase; 

security level (used) at calling user air interface; 

speech service requested; 

speech services supported; 

called/forwarded-to party address SSI and called/forwarded-to party extension; 

number of digits in called/forwarded-to external subscriber number; 

called/forwarded-to external subscriber number; 

calling party presentation indicator; 

(calling party) MSISDN present as external subscriber number; 

calling external subscriber number parameters; 

call identified as fleet call; 

calling party fleet number SSI; 

called/forwarded-to party fleet number SSI. 

In addition the calling external subscriber number is being encoded in a different manner which uses less 
bits. 
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NOTE 2: The originating SwMI MNI has been included in the definition of the TETRA PDU in table 26 to ease the 
identification of the originating SwMI for the called SwMI or the terminating SwMI (because to do it 
using the PISN number put in the calling party number information element of the PSSl SETUP 
message, as specified in subclause 6.2.1, might have proven problematic in some cases). 

Such identification is necessary: 

for enforcing some security mechanisms agreed between operators; or 

to be able to identify whether a proprietary feature can or cannot be used over an ISI; or 

to allow loop connection (notably trombone connection) detection. 

NOTE 3: The information element last forwarding SwMI MNI is only needed for the routing operation of the call 
forwarding supplementary services by the invoked ANF-ISIIC. In addition, even when no call forwarding 
supplementary service is invoked for the called user, it is helpful for the terminating SwMI to identify that 
the call has been routed by forward switching through the home SwMI of the called user when that SwMI 
is SwMI B and that user has migrated (to SwMI C, the terminating SwMI). 

The information element forward switched allows not to include the information element last forwarding 
SwMI MNI when the call has not been forward switched. 

The information element SS-CF invocation counter is present only because of the interactions between 
the call forwarding supplementary services and ANF-ISIIC: to limit the number of invocations (and 
operations) of those supplementary services for the same call. 

NOTE 4: See subclauses 6.3.2.2.42 and 6.3.2.2.46 for the definitions of the information elements routing method 
choice and speech services supported, respectively. 

6.3.1 .2 TETRA PDU giving complementary information in a PSS1 PROGRESS 

message 

According to clause 10 of ISO/IEC 11572 [16], a PROGRESS message will only be sent in the case of interworking 
with a non-TETRA network, i.e. in the case of an external call (since no SwMI involved in the call set-up will send 
in-band information/patterns otherwise). The contents of TETRA PDU in this message and its encoding shall be as 
defined in table 27. 

Table 27: Contents of TETRA PDU sent in PSSl PROGRESS message 



Information element 


Length 


Type 


Owner 


C/O/IM 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-PROGRESS 


Call time-out, set-up phase 


3 


1 


CCAp 


M 




Hook method selection 


1 


1 


CCAp 


M 




Simplex/duplex selection 


1 


1 


CCAp 


M 




Call status 


3 


2 


CCAp 







Basic service information 


8 


2 


CCAp 





note 


Speech service chosen 


3 


2 


CCAp 





note 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 







NOTE: IVIandatory when it is different from requested and when this information element has not already been 
sent. Otherwise, this information element shall not be included. 



NOTE: The definition of this PDU has been done on the basis of that of the D-CALL PROCEEDING air 

interface downlink PDU - except for the addition of the optional information element defining the speech 
service chosen and the deletion of the facility information element. 
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6.3.1 .3 TETRA message sent by the called SwMI in a PSS1 FACILITY message 

when it is not the terminating SwMI because of migration or SS-CF 
invocation 

When no call forwarding supplementary service is invoked for the call, the called SwMI is different from the 
terminating SwMI only when: 

it (i.e. the called SwMI) is the home SwMI of the called user; and 

the called user has migrated. 

The called SwMI may also be different from the terminating SwMI as a result of the operation of a call forwarding 
supplementary service invoked for the call. 

The called SwMI will then send to the originating SwMI a PSSl FACILITY message including a TETRA PDU, the 
contents and the encoding of which shall be as defined in table 28. 

Table 28: Contents of TETRA PDU sent by the called SwMI in a PSS1 FACILITY message in case 
it is not the terminating SwMI because of migration of the called user or of SS-CF invocation 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU-Type 


6 


1 


CCAp 


M 


ISI-REDIRECT 


Possible ISI trombone or loop connection detected 


1 


1 


ANF 


M 


note 1 


Routing method response 


3 




ANF 


C 


note 2 


Called/forwarded-to user having migrated 


1 




ANF 


C 


note 2 


Visited/forwarded-to SwIVII MNI 


24 




ANF 


C 


note 3 


Number of digits in visited/forwarded-to SwMI PISN number 


5 




ANF 


C 


notes 3 and 4 


Visited/forwarded-to SwIVII PISN number 


variable 




ANF 


C 


notes 3 and 5 


SS-CF invocation counter 


5 


1 


SS 


M 




SS-CF invoked 


1 


1 


SS 


M 


note 6 


Forwarded-to user SSI 


24 




SS 


C 


note 7 


Forwarded-to user extension 


24 




SS 


C 


note 7 


Number of digits in forwarded-to external subscriber number 


5 




SS 


c 


notes 7 and 8 


Forwarded-to external subscriber number 


variable 




SS 


c 


notes 


Call identified as fleet call 


1 


1 


CCAp 


M 




Calling party fleet number SSI 


24 




CCAp 


C 


note 1 


Called/forwarded-to party fleet number SSI 


24 




CCAp 


C 


note 10 


PDU addressed to originating SwIVII 


1 


1 


ANF 


M 


note 1 1 


Cause for PDU addressed to originating SwIVII 


3 




ANF 


C 


note 12 


Incoming call barring status 


2 




ANF 


C 


notes 1 2 and 1 3 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








£75/ 



75 



ETSI TS 100 392-3-2 V1.1.1 (2000-10) 



Information element 



Length | Type | Owner | C/O/M | 



Remark 



NOTE 1 : If no SS-CF has been invoked, the only possible case of ISI trombone or loop connection which can occur 
is when the called party has migrated into the originating SwIVII. Actually in such a case, only an ISI 
trombone connection could occur if the call was forward switched in the SwIVII which sends this 
ISI-REDIRECTPDU. 

If SS-CF has been invoked and the call forward switched at least once, the cases which can occur and be 
detected by the SwIVII which sends this ISI-REDIRECT PDU are the following: 

- an ISI trombone connection with the preceding SwMI (i.e. the one which has sent the corresponding 
ISI-SETUPPDU);or 

- an ISI loop connection with the originating SwIVII (possibly reduced to a trombone if the connection 
with the originating SwIVII was established backwards through all the same SwIVIIs already on the 
path). 

The SwIVII which sends this ISI-REDIRECT PDU shall detect the above cases of ISI trombone or loop 
connection with the originating SwIVII. If it detects such possible ISI loop (else trombone - see above) 
connection with the originating SwIVII in the case where SS-CF has been invoked and the call forward 
switched at least once, it shall then send this ISI-REDIRECT PDU directly to the originating SwIVII (see 
subclause 6.3.3). In addition, it should detect the possible ISI trombone connection with the preceding 
SwIVII when that SwMI is different from the originating SwIVII, i.e. in the case where SS-CF has been 
invoked and the call forward switched at least once. 

NOTE 2: Conditional on the value of the information element "Possible ISI trombone or loop connection detected" 
indicating that the SwMI by the SwMI sending this ISI-REDIRECT PDU has not detected the possibility of 
such ISI trombone or loop connection. 

If such an ISI trombone connection with the preceding SwMI could occur but this had not been detected 
by the SwMI sending this ISI-REDIRECT PDU (i.e. that SwMI is different from the originating SwMI), that 
preceding SwMI (which receives this PDU) may avoid it by identifying the MNI in this information element 
as being its own. 

NOTE 3: Conditional on the value of the information element "called/forwarded-to user having migrated" indicating: 

- if no SS-CF is invoked, that the called user (or the SS-CF served user if SS-CF has been invoked 
previously) has migrated; 

- if SS-CF is invoked, that the forwarded-to user has migrated. 

Note that in either case, the case where such migration would take place into the originating SwMI will be 

excluded since in that case the information element "called/forwarded-to user having migrated" shall not 

be present (see note 2). 

Shall be equal to N, N being the number of digits which the visited/forwarded-to SwMI PISN number 

comprises. 

The length in bits of this information element shall be equal to 4 x N, N being the number of digits in the 

visited/forwarded-to SwMI PISN number (see note 4). 

Allows to distinguish between migration of the called user indicated in the corresponding ISI-SETUP PDU 

and operation of a call forwarding supplementary service invoked in the SwMI sending this 

ISI-REDIRECT PDU; if SS-CF has been invoked, if the SwMI sending this ISI-REDIRECT PDU is the 

forwarded-to user and if that user has migrated, this PDU shall contain elements pertaining to both. 

Conditional on the value of the information element SS-CF invoked indicating that such SS-CF information 

is present. 

Shall be equal to when no forwarded-to external subscriber number is present, or to N, N being the 

number of digits which the forwarded-to external subscriber number comprises. 

The length in bits of this information element shall be equal to 4 x N, N being the number of digits in the 

forwarded-to external subscriber number (see note 8), i.e. this information element shall be conditional on 

the value of N. 

Conditional on the value of the information element call identified as fleet call indicating that the call has 

been identified as being a fleet call. 

The value of this information element shall correspond to the addressing of this ISI-REDIRECT PDU to 

the originating SwMI: 

- in the cases of possible ISI trombone or loop connection with the originating SwMI as provided in 
note 1 above; or 

- in the specific cases of SS-CF served user migration in the originating SwMI identified by specific 
values of the following information element: cause for PDU addressed to originating SwMI. 

NOTE 12: Conditional on the value of the information element "PDU addressed to originating SwMI" indicating that 
this ISI-REDIRECT PDU is addressed to the originating SwMI. 

NOTE 13: Conditional on the binary value of the information element cause for PDU addressed to originating SwMI 
being smaller than 01 1 2- It shall then apply to the called user (or if SS-CF has been invoked, to the SS-CF 
served user) - to take into account the interactions with local SS-BIC and SS-CAD. 



NOTE 4: 


NOTE 5: 


NOTE 6: 


NOTE 7: 


NOTE 8: 


NOTE 9: 


NOTE 10 


NOTE 1 1 
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6.3.1.4 



TETRA message sent by the originating SwMI in a PSS1 FACILITY message 
to request forward switching 

After having received the PSSl FACILITY message defined in table 28 (whereby the called SwMI informs the 
originating SwMI that the call has to be re-directed to a third SwMI), the originating SwMI may decide to have the call 
forward switched in the called SwMI. It will then send a PSSl FACILITY message including a TETRA PDU, the 
contents and the encoding of which shall be as defined in table 29. 

Table 29: Contents of TETRA PDU possibly sent by the originating SwMI in a PSS1 FACILITY 

message in response to ISI-REDIRECT PDU 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-FORWARD SWITCH 


Proprietary 




3 


- 








6.3.1 .5 TETRA PDU giving complementary information in the PSSl ALERTING 

message 

The contents of this PDU and its encoding shall be as defined in table 30. 

Table 30: Contents of TETRA PDU sent in the PSS1 ALERTING message 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-ALERTING 


Call time-out, set-up phase 


3 


1 


CCAp 


M 




Hook method selection 


1 


1 


CCAp 


M 




Simplex/duplex selection 


1 


1 


CCAp 


M 




Call status 


4 


2 


CCAp 


M 


note 1 


Basic service information 


8 


2 


CCAp 





note 2 


Speech service chosen 


3 


2 


CCAp 





note 2 


Notification indicator 


6 


2 


ss 







Proprietary 




3 


- 







NOTE 1 : If present this information element shall take only the values corresponding to call queued or call waiting 

(the latter corresponding to SS-CW being invoked by the called user). 
NOTE 2: Mandatory when it is different from requested or from that already sent in another TETRA PDU (i.e. in a 

PSSl FACILITY or PROGRESS message). Otherwise, this information element shall not be included. 



NOTE: The information element hook method selection has been included in table 30 for the purpose of 

alignment with the D-ALERT air interface downlink PDU (see table 60 of EN 300 392-2 [1]). However it 
should be noted that it is needed neither at the ISI nor at the air interface since the mere sending of an 
ALERTING message or of a D-ALERT PDU implies that the hook selection method chosen by the called 
user is on/off hook signalling. 
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6.3.1 .6 TETRA PDU giving complementary information in the PSS1 CONNECT 

message 

The contents of this PDU and its encoding shall be as defined in table 3 1 . 

Table 31 : Contents of TETRA PDU sent in the PSS1 CONNECT message 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 




CCAp 


M 


ISI-CONNECT 


Terminating SwMI MNI 


24 




ANF 


M 




Call diverted to a dispatcher 


1 




ANF 


M 




Call time-out 


4 




CCAp 


M 




Hook method selection 


1 




CCAp 


M 




Simplex/duplex selection 


1 




CCAp 


M 




Transmission grant 


2 




CCAp 


M 


note 1 


Transmission request permission 


1 




CCAp 


M 


note 1 


Call ownership 


1 




CCAp 


M 


note 2 


Connected party presentation indicator 


2 




SS 


M 




Connected party SSI 


24 




CCAp 


M 


note 3 


Connected party extension 


24 




CCAp 


M 


note 4 


Number of digits in connected external subscriber number 


5 




CCAp 


M 


note 5 


Connected external subscriber number 


variable 




CCAp 


C 


note 6 


MSISDN present as external subscriber number 


1 




CCAp 


C 


note 7 


Connected external subscriber number parameters 


9 




CCAp 


C 


note 7 


Call identified as fleet call 


1 


1 


CCAp 


M 




Connected party fleet number SSI 


24 




CCAp 


C 


notes 


Call priority 


4 


2 


CCAp 





note 9 


Basic service information 


8 


2 


CCAp 





note 9 


Speech service chosen 


3 


2 


CCAp 





note 9 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 







NOTE 1 : The contents of this information element shall be ignored (see note 1 below this table). 

NOTE 2: This element is needed in the case of call collision. 

NOTE 3: In the case of an external outgoing call, the connected party SSI shall be that of the outgoing gateway 

SwMI. 
NOTE 4: In the case of an external outgoing call, the connected party extension shall be that of the outgoing 

gateway SwIVII. 
NOTE 5: Shall be equal to when no connected external subscriber number is available or applicable, or to N, N 

being the number of digits which the connected external subscriber number comprises. 
NOTE 6: The length in bits of this information element shall be equal to 4 x N, N being the number of digits in the 

external subscriber number (see note 5), i.e. this information element shall be conditional on the value 

of N. 
NOTE 7: Conditional on the value of the information element number of digits in connected external subscriber 

number being different from 0. 
NOTE 8: Conditional on the value of the information element call identified as fleet call indicating that the call has 

been identified as being a fleet call. 
NOTE 9: Mandatory when it is different from requested or from that already sent in another TETRA PDU. 

Otherwise, this information element shall not be included. 



NOTE 1 : The two information elements transmission grant and transmission request permission have been included 
in table 31 for the purpose of alignment with the D-CONNECT air interface downlink PDU (see table 63 
of EN 300 392-2 [1]). However it should be noted that they are not needed at the ISI for individual calls 
because the originating SwMI being the controlling SwMI, the terminating SwMI (which sends this ISI 
CONNECT message) may not take any decision about those information elements. 

NOTE 2: The term "connected party" has been preferred to "called party" in the definition of two information 
elements in table 31 to be aligned with the definition of the PSSl CONNECT message, in 
subclause 13.2.3 of ISO/IEC 11572 [16]. It anticipates possible interactions with supplementary services 
which modify the addressee of the call (e.g. supplementary services call forwarding or call authorized by 
dispatcher). In the absence of such interaction, the connected party will be the called party. 
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6.3.1 .7 TETRA information sent by the terminating SwMI in PSS1 FACILITY 

messages before the PSS1 ALERTING or CONNECT message 

The terminating SwMI may inform the originating SwMI about some characteristics requested in the set-up that it does 
not support before the PSSl ALERTING or CONNECT message has been sent. It will do this by sending a TETRA 
PDU in a PSSl FACILITY message, the contents and the encoding of which shall be as defined in table 32. 

Such PSSl FACILITY message including this same TETRA PDU may also be sent by a SwMI outgoing gateway, 
instead of the PSSl PROGRESS message including the TETRA PDU defined in table 27. 

Table 32: Contents of TETRA PDU (possibly) sent in a PSSl FACILITY message 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-CALL PROCEEDING 


Call time-out, set-up phase 


3 


1 


CCAp 


M 




Simplex/duplex selection 


1 


1 


CCAp 


M 




Call status 


3 


2 


CCAp 







Basic service information 


8 


2 


CCAp 





note 


Speech service chosen 


3 


2 


CCAp 





note 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 







NOTE: IVlandatory when it is different from requested. Otherwise, this information element shall not be included. 



NOTE 1 : Except for the value of the PDU type information element and for the absence of the information element 
hook method selection, this PDU definition is the same as that in table 27. 

NOTE 2: The information element hook method selection has not been included in table 32, because only the called 
user may decide which hook method it selects. 

If the terminating SwMI decides to prolong the call set-up time on its side while no other information is to be sent to the 
originating SwMI, it may send a PSSl FACILITY message including a TETRA PDU, the contents and the encoding of 
which shall be as defined in table 33. 

Table 33: Contents of TETRA PDU (possibly) sent in a PSSl FACILITY message 
to inform about prolongation of the call set-up time 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-SETUP PROLONGATION 


Call time-out, set-up phase 


3 


1 


CCAp 


M 




Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








6.3.1 .8 TETRA information sent by the terminating SwMI in a PSSl FACILITY 
message during call establishment after the PSSl ALERTING or CONNECT 
message 

If the terminating SwMI decides to prolong the call set-up time on its side after the PSSl ALERTING or CONNECT 
message has been sent (but of course before the call has been established - i.e. it has not yet sent the D-CONNECT 
ACKNOWLEDGE air interface downlink PDU), it will send a PSSl FACILITY message including the same TETRA 
PDU as if it would if it had taken this decision before sending the PSSl ALERTING message if the call is using on/off 
hook signalling, or the PSSl CONNECT message if is using direct set-up signalling (i.e. the same TETRA PDU as 
defined in table 33). 

6.3.1 .9 TETRA information sent by the originating SwMI in a PSSl FACILITY 
message before the call has been established 

If the originating SwMI decides to prolong the call set-up time on its side, it will send a PSSl FACILITY message 
including a TETRA PDU, the contents and the encoding of which shall be as defined in table 33. 
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6.3.1 .10 TETRA CONNECT ACKNOWLEDGE sent by the originating SwMI in a PSS1 
FACILITY message 

To acknowledge the PSSl CONNECT message (in guaranteeing that a radio traffic channel has been to the calling 
user), the originating SwMI will send an ISI-CONNECT ACKNOWLEDGE PDU. This will be done using a PSSl 
FACILITY message including a TETRA PDU, the contents and the encoding of which shall be as defined in table 34. 

Table 34: Contents of TETRA PDU sent in a PSSl FACILITY message 
to acknowledge the CONNECT message (CONNECT ACKNOWLEDGE) 



Information element 


Length 


Type 


Owner 


C/O/IM 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-CONNECT ACKNOWLEDGE 


Call time-out 


4 


1 


CCAp 


M 




Transmission grant 


2 


1 


CCAp 


M 




Transmission request permission 


1 


1 


CCAp 


M 




Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








6.3.1 .1 1 Other TETRA messages possibly sent by the originating SwMI in PSSl 

FACILITY messages 

To inform the terminating SwMI that permission to transmit has been granted to the connected user, the originating 
SwMI will send an ISI-TX GRANTED PDU. This shall be done using a PSSl FACILITY message including a TETRA 
PDU, the contents and the encoding of which shall be as defined in table 35. 

Table 35: Contents of TETRA PDU sent in a PSSl FACILITY message 
to grant transmission permission (ISI-TX GRANTED) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-TX GRANTED 


Transmission grant 


2 


1 


CCAp 


M 




Transmission request permission 


1 


1 


CCAp 


M 




Encryption control 


1 


1 


CCAp 


M 




Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








To inform the terminating SwMI that the connected user is to be interrupted by the calling user, the originating SwMI 
will send an ISI-TX INTERRUPT PDU. This shall be done using a PSSl FACILITY message including a TETRA 
PDU, the contents and the encoding of which shall be as defined in table 36. 

Table 36: Contents of TETRA PDU sent in a PSSl FACILITY message 
to interrupt transmission by the connected user (ISI-TX INTERRUPT) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-TX INTERRUPT 


Transmission grant 


2 


1 


CCAp 


M 




Transmission request permission 


1 


1 


CCAp 


M 




Encryption control 


1 


1 


CCAp 


M 




Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








NOTE: The definitions of the ISI-TX GRANTED and ISI-TX INTERRUPT PDUs in tables 35 and 36 have been 
simplified compared to those of the corresponding air interface D-TX GRANTED and D-TX 
INTERRUPT PDUs. Notably, those ISI PDUs do not include the following information elements: 

the information elements identifying the transmitting party, because there are only useful for a group 
call and the goal of aligning ANF-ISIGC PDUs with the corresponding ANF-ISIIC ones has been 
abandoned; 
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the facility information element, as in every other ISI PDUs, since, as already mentioned in note 1 of 
subclause 6.3.1.1, ANF-ISISS is used instead (see clauses 9 and 10 of EN 300 392-9 [5]). 

To inform the terminating SwMI that transmission has ceased and that the called user may request transmission 
permission, the originating SwMI will send an ISI-TX CEASED PDU. This shall be done using a PSSl FACILITY 
message including a TETRA PDU, the contents and the encoding of which shall be as defined in table 37. 

Table 37: Contents of TETRA PDU sent in a PSS1 FACILITY message by the originating SwMI 
to inform that transmission has ceased (ISI-TX CEASED) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-TX CEASED 


Transmission request permission 


1 


1 


CCAp 


M 




Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








To inform the terminating SwMI regarding continuation of transmission (after it has been interrupted), the originating 
SwMI will send an ISI-TX CONTINUE PDU. This shall be done using a PSSl FACILITY message including a 
TETRA PDU, the contents and the encoding of which shall be as defined in table 38. 

Table 38: Contents of TETRA PDU sent in a PSS1 FACILITY message by the originating SwMI 
on transmission continuation (ISI-TX CONTINUE) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-TX CONTINUE 


Continue 


1 


1 


CCAp 


M 




Transmission request permission 


1 


1 


CCAp 


M 




Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








6.3.1 .12 TETRA messages possibly sent by either the originating or the terminating 
SwMI in a PSSl FACILITY message 

To inform the other end SwMI that it has interrupted transmission, the originating or the terminating SwMI will send an 
ISI-TX WAIT PDU. This shall be done using a PSSl FACILITY message including a TETRA PDU, the contents and 
the encoding of which shall be as defined in table 39. 

Table 39: Contents of TETRA PDU sent in a PSSl FACILITY message 
to interrupt transmission (ISI-TX WAIT) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-TX WAIT 


Transmission request permission 


1 


1 


CCAp 


M 




Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 
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To inform the other end SwMI that it wants some call modification or simply call continuation (both as specified in 
subclause 14.5.1.2 of EN 300 392-2 [1]) and/or to send DTMF information and/or notifications, the originating or the 
terminating SwMI will send an ISI-"INFO" DEMAND PDU. This shall be done using a PSSl FACILITY message 
including a TETRA PDU, the contents and the encoding of which shall be as defined in table 40. 

Table 40: Contents of TETRA PDU sent in a PSSl FACILITY message 
to request some call modification (ISI- "INFO " DEMAND) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-INFO DEMAND 


Call time-out 


4 


2 


CCAp 





note 1 


Modify request 


9 


2 


CCAp 







Speech service requested/chosen 


3 


2 


CCAp 





notes 2 and 3 


Speech services supported 


8 


2 


CCAp 





note 4 


Notification indicator 


6 


2 


SS 







Call status 


? 


2 


SS 





note 5 


DTMF 


variable 


3 


CCAp 







Proprietary 




3 


- 







NOTE 1 : Shall only be sent if the sending SwMI has decided to change the duration of the call in updating the 

equivalent information element to the user that it controls (by a D-INFO air interface PDU). 
NOTE 2: Mandatory if the value of the information element modify request corresponds to a change from a data call 

to a speech call. Also mandatory to change the speech service during a speech call. Otherwise, this 

information element shall not be included. 
NOTE 3: The meaning of this information element is speech service chosen when this PDU is used instead of ISI- 

ALERTING PDU (see e.g. SS-CAD). 
NOTE 4: May be present only when the information element speech service requested(/chosen) is present (see 

note 2). 
NOTE 5: This information element is used by the SS-CFNRy, SS-CAD, SS-CW and SS-HOLD protocols (only with 

the value corresponding to call queued by the SS-CFNRy protocol, with the value corresponding to call 

waiting by the SS-CW protocol and with the values corresponding to call put on hold and call on hold 

retrieved by the SS-HOLD protocol). 



If the contents of the TETRA PDU defined in table 40 calls for a response, upon receiving the PSS 1 FACILITY 
message including it, the other end SwMI will send a PSSl FACILITY message including a TETRA PDU, the contents 
and the encoding of which shall be as defined in table 41. 

Table 41 : Contents of TETRA PDU sent in a PSSl FACILITY message 
in reply to a call modification request (ISI- "INFO " REPLY) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-INFO REPLY 


Call time-out 


4 


2 


CCAp 





note 1 


Modify accepted 


9 


2 


CCAp 





note 2 


Speech service chosen 


3 


2 


CCAp 





note 3 


DTMF 




3 


CCAp 







Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 







NOTE 1 : Mandatory when it is different from that sent by the other end SwMI in the preceding ISI-INFO DEMAND 

PDU. Otherwise, this information element shall not be included. 
NOTE 2: Mandatory when it is different from requested. Otherwise, this information element shall not be included. 
NOTE 3: Mandatory when it is different from that sent by the other end SwMI in the preceding ISI-INFO DEMAND 

PDU. Otherwise, this information element shall not be included. 
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6.3.1 .13 TETRA messages possi 
messages 



ibiy sent by the terminating SwMI in PSS1 FACILITY 



To request transmission grant from the originating SwMI, the terminating SwMI will send an ISI-TX DEMAND PDU. 
This shall be done using a PSSl FACILITY message including a TETRA PDU, the contents and the encoding of which 
shall be as defined in table 42. 

Table 42: Contents of TETRA PDU sent in a PSSl FACILITY message 
to request transmission grant (ISI-TX DEMAND) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-TX DEMAND 


TX demand priority 


2 


1 


CCAp 


M 




Encryption control 


1 


1 


CCAp 


M 




Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








NOTE: The definition of the ISI-TX DEMAND PDU in table 42 has been derived from that of the corresponding 
air interface U-TX DEMAND PDU in: 

removing the information elements: 

call identifier (specific to air interface PDUs); 

DM-MS address (specific to some air interface PDUs - used for Direct Mode Operation); 

facility, as in every other ISI PDUs, since, as already mentioned in note 1 of subclause 6.3.1.1, 
ANF-ISISS is used instead (see clauses 9 and 10 of EN 300 392-9 [5]); and 



the 1 bit reserved one; 



and 



adding the notification indicator information element. 

To inform the originating SwMI that transmission has ceased, the terminating SwMI will send an ISI-TX CEASED 
PDU. This shall be done using a PSSl FACILITY message including a TETRA PDU, the contents and the encoding of 
which shall be as defined in table 43. 

Table 43: Contents of TETRA PDU sent in a PSSl FACILITY message 
to inform that transmission has ceased (ISI-TX CEASED) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-TX CEASED 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








To inform the originating SwMI that it is ready to continue transmission (after having interrupted it), the terminating 
SwMI will send an ISI-TX CONTINUE PDU. This shall be done using a PSSl FACILITY message including a 
TETRA PDU, the contents and the encoding of which shall be as defined in table 44. 

Table 44: Contents of TETRA PDU sent in a PSS1 FACILITY message by the terminating SwMI 
on transmission continuation (ISI-TX CONTINUE) 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-TX CONTINUE 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 
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6.3.1 .14 TETRA PDUs giving complementary information in PSS1 messages to 

restore the call after the calling or the connected user has migrated in a new 
SwMI 

When one of the two users participating in an estabHshed individual call migrates during this call, the call control 
application in the SwMI in which this user was previously registered will be informed by ANF-ISIMM about this 
migration. This information will include the MNI of the new SwMI where the user is now registered and may include 
the PISN number to be used for establishing a connection between the old SwMI and that new SwMI, to allow a 
subsequent call restoration, unless such connection already exists because the new SwMI coincides with either the other 
end SwMI (i.e. either the originating or the terminating SwMI) or the forward switching SwMI. If such PISN number is 
not delivered by ANF-ISIMM, then the old SwMI will use the PISN number corresponding to the new SwMI MNI in its 
routing table. 

6.3.1.14.1 Case where no connection between the old SwMI and the new SwMI already 

exists or has been identified 

If the connection between the old SwMI and the new SwMI does not already exist or has not been identified, it may be 
set-up by the ANF-ISIIC entity in the old SwMI. If the call was an inter-TETRA call, this will be part of the operation 
of the ANF-ISIIC invoked for that call. If the established call was an intra-TETRA call, an ANF-ISIIC will be invoked 
to establish this connection. In both cases, the old SwMI will send a PSSl SETUP message including a TETRA PDU, 
the contents and the encoding of which shall be as defined in table 45. 

Table 45: Contents of TETRA PDU in PSS1 SETUP message sent by the old SwMI 
in the case of migration during an established call 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 




CCAp 


M 


ISI-CALL RESTORE PREPARE 


Other end SwMI MNI 


24 




ANF 


M 




Call time-out 


4 




CCAp 


M 




Simplex/duplex selection 


1 




CCAp 


M 




Basic service information 


8 




CCAp 


M 




Speech service used 


3 




CCAp 


C 


note 1 


Security level at calling user air 
interface 


2 




MM 


M 


notes 2 and 3 


Controlling SwMI 


1 




CCAp 


M 




Transmission grant 


2 




CCAp 


M 




Transmission request permission 


1 




CCAp 


M 




Call priority 


4 




CCAp 


M 




Call identifier 


14 




CCAp 


M 




Restoring party SSI 


24 




CCAp 


M 


note 4 


Restoring party extension 


24 




CCAp 


M 


note 4 


SS-CLIR invoked for other party 


1 




SS 


M 




Other party SSI 


24 




CCAp 


M 


note 5 


Other party extension 


24 




CCAp 


M 


note 5 


Speech services supported 


8 


2 


CCAp 





note 6 


Proprietary 




3 


- 







NOTE 1 : Conditional on the binary value of the information sub-element circuit mode type in the information 
element basic service information being equal to (i.e. the call requested is a speech call). 

NOTE 2: This information element, which defines the security level that the originating SwMI requested at call set- 
up time the terminating SwMI to match, is sent independently of whether the "old SwMI" is the originating 
SwMI or the terminating SwMI. 

NOTE 3: In the case of an external incoming call from PSTN/ISDN/PISN, the name of this information element 
should be understood as "security level used in the other network". 

NOTE 4: The case where the restoring party SSI and the restoring party extension would be those of a gateway is 
excluded. 

NOTE 5: In the case of an external call, the other party SSI and the other party extension shall be those of the 
gateway. 

NOTE 6: May be present only when the information element speech service requested is present (see note 1). 
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NOTE: The two information elements defining the restoring party ITSI have been included in the table above 
because it was felt that the call identifier value included in this table might not always allow the new 
SwMI to associate the connection being established to this party when it restores the call (especially since 
the call identifier value included in this table is not a new SwMI call identifier). 

As to the two information elements defining the other party ITSI, they have been included to support the 
redundancy mechanism provided by the inclusion of these elements in the definition of the air interface 
U-CALL RESTORE message (see table 78 of EN 300 392-2 [1]). 

To indicate that it accepts the PSSl SETUP message, if it has not yet received the call restoration message from its new 
visiting user, the new SwMI will send a PSSl CONNECT message including only a specific PDU type as defined in 
table 46. 

Table 46: Contents of TETRA PDU sent in the PSSl CONNECT message 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-CALL RESTORE PREPARED 



Then, when the new SwMI receives the call restoration message from its new visiting user, it will send a PSSl 
FACILITY message including a TETRA PDU, the contents and the encoding of which shall be as defined in table 47. 

Table 47: Contents of TETRA PDU in PSSl FACILITY message sent by the new SwMI 

in the case of call restoration 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-CALL RESTORATION 


New SwMI MNI 


24 


1 


ANF 


M 




Controlling SwMI 


1 


1 


CCAp 


M 




Transmission grant 


2 




CCAp 


C 


note 1 


Transmission request permission 


1 




CCAp 


C 


note 1 


Call time-out 


4 


2 


CCAp 





note 2 


Call status 


4 


2 


CCAp 


M 


note 3 


Call priority 


4 


2 


CCAp 





note 2 


Modify request 


9 


2 


CCAp 





note 4 


Speech service chosen 


3 


2 


CCAp 





note 5 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 







NOTE 1 : This information element shall be included if and only if the value of the information element controlling 
SwMI is equal to 1 (i.e. if the new SwMI is going to be the controlling SwMI - for the call). 

NOTE 2: Mandatory when the new SwMI has modified the value of this information element compared to that 

passed by the old SwMI in the corresponding ISI-CALL RESTORE PREPARE PDU or ISI-PATH CALL 
RESTORE PREPARE PDU. Otherwise, this information element shall not be included. 

NOTE 3: If present this information element shall take only the values corresponding to call queued or call on hold 
retrieved (the latter being possibly used only by the SS-HOLD protocol). 

NOTE 4: Mandatory when the new SwMI has modified the simplex/duplex selection or the basic service information 
of the call before the party restoring it migrated (i.e. when the simplex/duplex selection or the basic 
service information between the old SwMI and the other end SwMI have been modified by the new SwMI 
- that SwMI being informed about those used previously by the corresponding ISI-CALL RESTORE 
PREPARE PDU or ISI-PATH CALL RESTORE PREPARE PDU). Otherwise, this information element 
shall not be included. 

NOTE 5: Mandatory when the new SwMI has modified the value of this information element compared to that of the 
information element speech service used passed by the old SwMI in the corresponding ISI-CALL 
RESTORE PREPARE PDU or ISI-PATH CALL RESTORE PREPARE PDU. Otherwise, this information 
element shall not be included. 



If the new SwMI has received the call restoration message from its new visiting user in time, it will send the TETRA 
PDU defined in table 47 in the PSSl CONNECT message (instead of in a PSSl FACILITY message). 
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6.3.1.14.2 Cases where no new connection is needed between the old SwMI and the new 

SwMI 

There are two possible cases where no new (ISI) connection is needed between the old SwMI and the new SwMI: 

a) the call has been forward switched and the old SwMI has identified that the new SwMI coincides with the 
forward switching SwMI; 

NOTE 1: In the case of a basic individual call, there cannot be more than one forward switching SwMI (i.e. the 
called user home SwMI), but there may be more because of interactions with supplementary services 
which modify the routing of the call (e.g. call forwarding). However it should be noted that in the latter 
case the ANF-ISIIC PDUs have been specified, for simplicity purpose, in such a manner that they allow 
only each end SwMI to know the SwMI nearest from it where the call has been forward switched (e.g. for 
the originating SwMI, the home SwMI of the originally called user). Therefore if the call has been 
forward switched twice, the originating SwMI will not know the SwMI where the call has been forward 
switched for the second time. Also, if the call has been forward switched twice, the terminating SwMI 
will not know the SwMI where the call has been forward switched for the first time. If the call has been 
forward switched more than twice, neither the originating SwMI nor the terminating SwMI will know any 
of the forward switching SwMIs between the first and the last one on the path of the call. 

b) the new SwMI coincides with the other end SwMI (i.e. either the originating or the terminating SwMI). The call 
restoration could then result in the call becoming an intra-TETRA call. 

In case a), the old SwMI may send to the new SwMI on the path of the call a PS SI FACILITY message including a 
TETRA PDU, the contents and the encoding of which shall be as defined in table 48. 

Table 48: Contents of TETRA PDU in PSS1 FACILITY message sent by the old SwMI 

to the forward switching/new SwMI in the case of migration during an established call 

to avoid a trombone connection at call restoration 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 




CCAp 


M 


ISI-PATH CALL RESTORE PREPARE 


Other end SwMI MNI 


24 




ANF 


M 




Call time-out 


4 




CCAp 


M 




Simplex/duplex selection 


1 




CCAp 


M 




Basic service information 


8 




CCAp 


M 




Speech service used 


3 




CCAp 


C 


note 1 


Security level at calling user air 
interface 


2 




MM 


M 


notes 2 and 3 


Controlling SwIVII 


1 




CCAp 


M 




Transmission grant 


2 




CCAp 


M 




Transmission request permission 


1 




CCAp 


M 




Call priority 


4 




CCAp 


M 




Call identifier 


14 




CCAp 


M 




Restoring party SSI 


24 




CCAp 


M 


note 4 


Restoring party extension 


24 




CCAp 


M 


note 4 


SS-CLIR invoked for other party 


1 




SS 


M 




Other party SSI 


24 




CCAp 


M 


note 5 


Other party extension 


24 




CCAp 


M 


note 5 


Speech services supported 


5 


2 


CCAp 





note 6 


Proprietary 




3 


- 







NOTE 1 : Conditional on the binary value of the information sub-element circuit mode type in the information 
element basic service information being equal to (i.e. the call requested is a speech call). 

NOTE 2: This information element, which defines the security level that the originating SwMI requested at call set- 
up time the terminating SwMI to match, is sent independently of whether the "old SwMI" is the originating 
SwMI or the terminating SwMI. 

NOTE 3: In the case of an external incoming call from PSTN/ISDN/PISN, the name of this information element 
should be understood as "security level used in the other network". 

NOTE 4: The case where the restoring party SSI and the restoring party extension would be those of a gateway is 
excluded. 

NOTE 5: In the case of an external call, the other party SSI and the other party extension shall be those of the 
gateway. 

NOTE 6: May be present only when the information element speech service requested is present (see note 1). 
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NOTE 2: The ISI-PATH CALL RESTORE PREPARE PDU has been defined (in table 48) as a specific 

TETRA PDU, even though its contents is the same as that of the ISI-CALL RESTORE PREPARE PDU, 
defined in table 45, (except of course for the value of its information element PDU type), to allow the 
SwMI which receives it to identify that it is on the path of the call. 

When the forward switching/new SwMI receives the call restoration message from its new visiting user, it will send to 
the other end SwMI (i.e. either the originating or the terminating SwMI) a PSSl FACILITY message including the 
TETRA PDU defined in table 47. 

In case b) (i.e. the new SwMI coincides with the originating or the terminating SwMI), the old SwMI may send to the 
new SwMI a PSSl FACILITY message including a TETRA PDU, the contents and the encoding of which shall be as 
defined in table 49. 

Table 49: Contents of TETRA PDU sent by the old SwMI to the other end/new SwMI 
in a PSS1 FACILITY message to avoid a trombone or a loop connection at call restoration 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-END CALL RESTORE PREPARE 


Proprietary 




3 


- 








NOTE 3: If the old SwMI did not identify that the new SwMI coincides with the other end SwMI (i.e. case b) 
above), and thus sent the ISI-CALL RESTORE PREPARE PDU, defined in table 45, instead of the 
ISI-END CALL RESTORE PREPARE, defined in table 49, the resulting ANF-ISIIC routing would be: 

a trombone connection if the call has been established with no forward switching (either simply 
between SwMI A and SwMI B, or systematically re-routed) or if it has been forward switched but no 
other path can be established between the originating and terminating SwMIs than through all the 
SwMIs through which the call has been forward switched; 

a loop connection if the call has been forward switched and there exists a direct path between the 
originating and terminating SwMIs. 

Finally, the definition of an additional TETRA PDU is needed for addressing the following cases of simultaneous 
occurrence: 

of case b) for each user engaged in the call; or 

of case b) for one user and of case a) for the other. 

More specifically, the case of simultaneous occurrence of case b) for each user can be described as follows in calling 
the two end SwMIs SwMIg^^^jj and SwMIg|^jj2' case b) occurs for one user engaged in the call, say the one initially 
registered in SwMI^j^j^, and, before the ANF-ISIIC call restoration related to the migration of that user (into SwMIgj^(j2) 
has been completed, case b) also occurs for the other. 

Similarly the case of simultaneous occurrence of case b) for one user and of case a) for the other can be described as 
follows, still in calling the two end SwMIs SwMI^j^^j and SwMIgjjjj2 ^^"1 in calling the new SwMI (identified as being 
of the path of the call) for case a) is called SwMI^^^j^,^: 

case b) occurs for one user engaged in the call, say the one initially registered in SwMI^j^^j, and, before the 
ANF-ISIIC call restoration related to the migration of that user (into SwMIgjjj2) has been completed, case a) 
occurs for the other, i.e. that other user migrates to SwMIj^^^jj,^ (from SwMIgj^(j2)' or 

case a) occurs first for one user engaged in the call, say the one initially registered in SwMIgjj(j2' ^"d, before the 
ANF-ISIIC call restoration related to the migration of that user into SwMI^^^jj,^ has been completed, case b) 
occurs for the other, i.e. that other user migrates to SwMIgjjjj2 (from SwMIgj^^j^). 
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In all the cases mentioned above, the new SwMI for the first user for whom case b) occurs (i.e. SwMIgj^j2 in ^U 
examples given above) will send to the new SwMI for the other user (SwMIgj^^jj in the example given for the 
simultaneous occurrence of case b) for each user, or SwMIj^j^^ for the simultaneous occurrence of case b) for one user 
and of case a) for the other) a PSSl FACILITY message including a TETRA PDU, the contents and the encoding of 
which shall be as defined in table 50. 

Table 50: Contents of TETRA PDU sent by the old SwMI to the other end/new SwMI 
in a PSS1 FACILITY message to avoid a trombone or a loop connection at call restoration 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-SIMULTANEOUS MIGRATION 


Proprietary 




3 


- 








6.3.1 .15 TETRA PDUs giving complementary information in PSSl DISCONNECT 
messages 

Whenever a PSSl DISCONNECT message is sent to clear an invoked ANF-ISIIC, it will include a TETRA PDU, the 
contents and the encoding of which shall be as defined in table 5 1 . 

NOTE: The clearing of the invoked ANF-ISIIC may be the result of: 

the clearing of the corresponding call by any TETRA application on the path of the call, either during 
the establishment of the call or after it has been established (e.g. TETRA application for the calling 
user, the connected user, the originating SwMI or the terminating SwMI, including when the call is 
rejected by the called user, or by the terminating SwMI, e.g. because it cannot match the air interface 
security level requested by the originating SwMI - in the ISI-SETUP PDU); 

the clearing of the invoked ANF-ISIIC because the call has become an intra-TETRA call, because of: 

the invoked ANF-ISIIC has found out through trombone or loop detection that the originating and 
the terminating SwMIs coincide: the originating SwMI, informed about it through the 
ISI-REDIRECT PDU, defined in table 28, will then clear the invoked ANF-ISIIC in sending back 
a PSSl DISCONNECT message including the TETRA PDU defined in table 51; 



call restoration for one of the two users engaged in the (individual) call when that user has 
migrated into the other end SwMI (e.g. during the call the connected user migrates into the 
originating SwMI - where the call is restored). This corresponds to what has been identified as 
case b) in subclause 6.3.1.14.2; 



or 



only the clearing of an ISI connection, previously seized by the invoked ANF-ISIIC, which has 
become unnecessary. The clearing of the invoked ANF-ISIIC is only partial in such cases, which 
happen because of: 

- re-routing during the establishment of the call, e.g.: if after having received the PSS 1 FACILITY 
with the ISI-REDIRECT PDU, defined in table 28, because the called user has migrated in 
SwMI C, the originating SwMI decides to re-route the call, it will clear the ISI connection to the 
called SwMI (previously seized by the ISI-SETUP PDU sent to that SwMI) in sending a PSSl 
DISCONNECT message including the TETRA PDU defined in table 5 1 . The same re-routing 
operation may take place because of operation of a call forwarding supplementary service; 



call restoration for one of the two users engaged in the (individual) call when that user has 
migrated into a SwMI identified as being on the path of the call (e.g. the connected user was 
registered in SwMI C, the call has been forward switched through SwMI B, the connected user 
home SwMI and during the call that user migrates back into SwMI B - where the call is restored). 
This corresponds to what has been identified as case a) in subclause 6.3.1.14.2. 
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Table 51 : Contents of TETRA PDU sent in the PSS1 DISCONNECT message 
to clear the invoked ANF-ISIIC 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


6 


1 


CCAp 


M 


ISI-DISCONNECT 


Disconnect cause 


6 


1 


CCAp 


M 




Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 








6.3.1 .16 TETRA PDU giving complementary information in a PSS1 RELEASE 
message 

No TETRA PDU will be included in any PSSl RELEASE message (sent for an invoked ANF-ISIIC). 

NOTE: Subclause 10.2.2 of ISO/IEC 1 1572 [16] defines a call clearing exception condition (where the calling 

user initiates call clearing before an information channel has been agreed between any two adjacent PISN 
nodes, e.g. between the originating SwMI and the next node, or between the last but one node and the 
terminating SwMI) where either a PSSl DISCONNECT or a PSSl RELEASE message, but in such a 
case, there is no TETRA information worth sending. 

6.3.1 .17 TETRA PDUs giving complementary information in a PSSl RELEASE 
COMPLETE message 

If the called SwMI, or the terminating SwMI when it is different from the called SwMI, rejects the incoming call 
without having sent any prior PSSl message, then according to subclause 10.2.2 of ISO/IEC 11572 [16], it will send a 
PSSl RELEASE COMPLETE message, instead of a DISCONNECT message. Then if the situation is the same as one 
of those described in subclause 6.3.1.17, the corresponding TETRA PDU shall be included in this PSSl RELEASE 
COMPLETE message. This concerns the TETRA PDU defined in table 51. 

6.3.1 .18 TETRA PDUs specific for interaction with supplementary service protocol 
sent to the originating SwMI in a PSSl FACILITY message 

Due to the interaction with some supplementary services, it may happen that the call has been established for the calling 
user MS/LS and the originating SwMI while it is not established for the called user MS/LS nor for the terminating 
SwMI (e.g. call diverted to the dispatcher). In such a case, the originating SwMI shall receive a PSSl FACILITY 
message including: 

- the ISI-THROUGH ALERTING PDU if the call is alerting on the called side; 

- the ISI-THROUGH CONNECT PDU if the called user answers the call. 

The contents of ISI-THROUGH ALERTING PDU and its encoding shall be as defined in table 52. 

Table 52: Contents of TETRA PDU sent in a PSSl FACILITY message 
for informing the originating SwMI that the call is alerting on the called side 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-THROUGH ALERTING 


Call time-out, set-up phase 


3 


1 


CCAp 


M 




Hook method selection 


1 


1 


CCAp 


M 




Simplex/duplex selection 


1 


1 


CCAp 


M 




Call status 


4 


2 


CCAp 


M 


note 1 


Basic service information 


8 


2 


CCAp 





note 2 


Speech service chosen 


3 


2 


CCAp 





note 2 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 







NOTE 1 : If present this information element shall take only the values corresponding to call queued or call waiting 

(the latter corresponding to SS-CW being invoked by the called user). 
NOTE 2: Mandatory when it is different from requested or from that already sent in another TETRA PDU (i.e. in a 

PSS1 FACILITY or PROGRESS message). Otherwise, this information element shall not be included. 
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NOTE: See note in subclause 6.3.1.5. 
The contents of ISI-THROUGH CONNECT PDU and its encoding shall be as defined in table 53. 

Table 53: Contents of TETRA PDU sent in sent in a PSS1 FACILITY message 
for informing the originating SwMI that the call is answered 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


6 


1 


CCAp 


M 


ISI-THROUGH 
CONNECT 


Terminating SwIVII MNI 


24 




ANF 


M 




Call diverted to a dispatcher 


1 




ANF 


M 




Call time-out 


4 




CCAp 


M 




Hook method selection 


1 




CCAp 


M 




Simplex/duplex selection 


1 




CCAp 


M 




Connected party presentation indicator 


2 




SS 


M 




Connected party SSI 


24 




CCAp 


M 


note 1 


Connected party extension 


24 




CCAp 


M 


note 2 


Number of digits in connected external subscriber number 


5 




CCAp 


M 


note 3 


Connected external subscriber number 


variable 




CCAp 


C 


note 4 


IVISISDN present as external subscriber number 


1 




CCAp 


C 


note 5 


Connected external subscriber number parameters 


9 




CCAp 


C 


note 5 


Call identified as fleet call 


1 


1 


CCAp 


M 




Connected party fleet number SSI 


24 




CCAp 


C 


note 6 


Call priority 


4 


2 


CCAp 





note 7 


Basic service information 


8 


2 


CCAp 





note 7 


Speech service chosen 


3 


2 


CCAp 





note 7 


Notification indicator 


6 


2 


SS 







Proprietary 




3 


- 







NOTE 1 : In the case of an external outgoing call, the connected party SSI shall be that of the outgoing gateway 

SwMI. 
NOTE 2: In the case of an external outgoing call, the connected party extension shall be that of the outgoing 

gateway SwIVII. 
NOTE 3: Shall be equal to when no connected external subscriber number is available or applicable, or to N, N 

being the number of digits which the connected external subscriber number comprises. 
NOTE 4: The length in bits of this information element shall be equal to 4 x N, N being the number of digits in the 

external subscriber number (see note 3), i.e. this information element shall be conditional on the value 

of N. 
NOTE 5: Conditional on the value of the information element number of digits in connected external subscriber 

number being different from 0. 
NOTE 6: Conditional on the value of the information element call identified as fleet call Indicating that the call has 

been identified as being a fleet call. 
NOTE 7: Mandatory when it is different from requested or from that already sent in another TETRA PDU. 

Otherwise, this information element shall not be included. 



NOTE: See note 2 in subclause 6.3.1.6. 

6.3.2 TETRA PDU information element coding 

Of the information elements included in the TETRA PDU definitions in subclause 6.3.1: 

a number are identical to those defined for air interface messages (same names and definitions). Their definitions 
have not been reproduced in the present document - see subclause 14.8 of EN 300 392-2 [1] for those 
definitions; 

some have the same names as those defined for air interface messages but with different definitions, i.e. ISI 
specific. Their definitions are given in subclause 6.3.2.1; and 

the others are new. Their definitions are given in subclause 6.3.2.2. 

NOTE: A given PDU information element already defined for the air interface may or may not take all its 
possible values when used in ISI TETRA PDUs. 
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6.3.2.1 Specific IS! definition of some information elements already defined for air 

interface messages 



6.3.2.1.1 



Basic service information 



This information element shall be coded as defined in table 90 of EN 300 392-2 [1]. However when the value of its 
information sub-element circuit mode type corresponds to speech, the value of its other information sub-element speech 
service shall be ignored (see subclause 6.3.2.2.44). 

6.3.2.1.2 Call status 

The call status information element shall inform the other end SwMI about the status of the call as defined in table 54. 

Table 54: Call status information element contents 



Information element 


Length 


Value 


Remark 


Call status 


4 


OOOO2 


Call is proceeding (note) 


OOOI2 


Call is queued (note) 


001 O2 


Requested subscriber is paged (note) 


OOII2 


Call continue (note) 


OIOO2 


Hang time expired (note) 


OIOI2 


Reserved (note) 


OIIO2 


Reserved (note) 


OIII2 


Reserved (note) 


IOOO2 


Call waiting 


IOOI2 


Call put on hold 


IOIO2 


Call on hold retrieved 


>10102 


Reserved 


NOTE: All values OXXX2 shall be as defined in table 101 of EN 300 392-2 [1] for the same values (XXX2). The 
definitions given in the present table for those values are a copy of that table, to be considered for 
information only. 



6.3.2.1.3 



Call time-out, set-up phase 



First, as opposed to its definition for the air interface protocol, in subclause 14.8.17 of EN 300 392-2 [1], this 
information element shall not set the corresponding timer at the air interface at the other end SwMI (T301 in the case of 
the terminating SwMI, and T302 in that of the originating SwMI). It simply informs the other end SwMI about the call 
time-out in the set-up phase decided by the SwMI which is sending this information. 

NOTE 1 : The other end SwMI may then decide or not to update the relevant timer in the MS/LS involved in the 
call attempt. 

NOTE 2: While the value of the information element call time-out, set-up phase, sent by the terminating SwMI can 
be used directly by the originating SwMI to "start" (the meaning of "start" being as defined in 
subclause 14.5 of EN 300 392-2 [1]) timer T302 with this value, this is not the case for the terminating 
SwMI with timer T301. How the terminating SwMI handles this information element when it receives it 
is an implementation matter. 

Regarding the coding of this information element, it shall be as defined in table 105 of EN 300 392-2 [1], except that no 
predefined value shall be used (i.e. the value OOO2 shall be reserved). The resulting coding is defined in table 55. 
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Table 55: Call time-out, set-up phase information element contents 



Information element 


Length 


Value 


Remark 


Call time-out, set-up phase 


3 


OOO2 


Reserved 


001 2 


1 s 


01 O2 


2s 


0112 


5s 


1002 


10s 


1012 


20 s 


1102 


30 s 


1112 


60s 
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6.3.2.1.4 



Disconnect cause information element 



The purpose of the information element disconnect cause is to inform the SwMI to which the PSSl clearing message 
(DISCONNECT or possibly RELEASE COMPLETE) carrying this information element is sent, of the reason for that 
clearing. This information element shall be coded as defined in table 56. 

Table 56: Disconnect cause information element contents 



Information element Length Value 



Remark 



Disconnect cause 



Air interface specific disconnect causes 



OOOOOO2 



Cause not defined or unl<nown (note) 



000001 2 



User requested disconnect (note) 



00001 O2 



Called party busy (note) 



000011 2 



Called party not reachable (note) 



0001 OO2 



Called party does not support encryption (note) 



OOOIOI2 



Congestion in infrastructure (note) 



0001 IO2 



Not allowed traffic case (note) 



0001 II2 



Incompatible traffic case (note) 



OOIOOO2 



Requested service not available (note) 



OOIOOI2 



Pre-emptive use of resource (note) 



OOIOIO2 



Invalid call identifier (note) 



OOIOII2 



Call rejected by the called party (note) 



OOIIOO2 



No idle CC entity (note) 



OOIIOI2 



Expiry of timer (note) 



OOIIIO2 



SwIVII requested disconnection (note) 



OOIIII2 



Acknowledged service not completed (note) 



010000, 



Unknown TETRA identity (note) 



010001; 



SS-specific disconnection (note) 



OIOOIO2 



Unknown external subscriber identity (note) 



OIOOII2 



Call restoration of the other user failed (note) 



OIOIOO2 



Reserved (note) 



.etc. 



.etc. 



OIIIII2 



Reserved (note) 



ISI specific disconnect causes 



IOOOOO2 



Call rejected by the terminating/called SwIVII: cause unspecified 



100001 2 



Call rejected by the terminating/called SwMI because the security 
level at calling user air interface cannot be matched 



IOOOIO2 



Call re-routed 



IOOOII2 



No possible routing of the call 



IOOIOO2 



Call restored 



IOOIOI2 



ANF-ISIIC call restoration procedure not supported in new SwMI 



>10010l2 



Reserved 



NOTE: All values OXXXXX2 shall be as defined in table 1 06 of EN 300 392-2 [1 ] for the same values (XXXXX2). 

The definitions given in the present table for those values are a copy of that table, to be considered for 
information only. 
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6.3.2.1.5 



PDU type 



The purpose of the information element PDU type is to clearly identify the type of TETRA PDU sent over the ISI in a 
PSSl message. This information element shall be coded as defined in table 57. 

NOTE: A PDU type value has been defined for every possible TETRA PDU even for those which are the only 
one possibly sent in a given PSSl (basic call) message. 



Table 57: PDU type information element contents 



Information element 



Length 



Value 



Remark 



PDU Type 



OOOOOO2 



ISI-ALERTING (see table 30) 



000001 2 



ISI-CALL PROCEEDING (see table 32) 



00001 O2 



ISI-CALL RESTORE PREPARE (see table 45) 



000011 2 



ISI-CALL RESTORE PREPARED (see table 46) 



0001 OO2 



ISI-CALL-RESTORATION (see table 47) 



OOOIOI2 



ISI-CONNECT (see table 31) 



0001 IO2 



ISI-CONNECT ACKNOWLEDGE (see table 34) 



0001 II2 



ISI-DISCONNECT (see table 51) 



OOIOOO2 



ISI-END CALL RESTORE PREPARATION (see table 49) 



OOIOOI2 



ISI-FORWARD SWITCH (see table 29) 



OOIOIO2 



ISI-INFO DEMAND (see table 40) 



OOIOII2 



ISI-INFO REPLY (see table 41) 



OOIIOO2 



ISI-PATH CALL RESTORE PREPARATION (see table 48) 



OOIIOI2 



ISI-PROGRESS (see table 27) 



OOIIIO2 



ISI-REDIRECT (see table 28) 



OOIIII2 



ISI-RELEASE (see table 27) 



OIOOOO2 



ISI-SETUP (see table 26) 



OIOOOI2 



ISI-SETUP PROLONGATION (see table 33) 



OIOOIO2 



ISI-SIMULTANEOUS MIGRATION (see table 50) 



OIOOII2 



ISI-THROUGH ALERTING (see table 52) 



OIOIOO2 



ISI-THROUGH CONNECT (see table 53) 



OIOIOI2 



ISI-TX CEASED (see tables 37 and 43) 



OIOIIO2 



ISI-TX CONTINUE (see tables 38 and 44) 



OIOIII2 



ISI-TX DEMAND (see table 42) 



OIIOOO2 



ISI-TX GRANTED (see table 35) 



OIIOOI2 



ISI-TX INTERRUPT (see table 36) 



OIIOIO2 



ISI-TX WAIT (see table 39) 



>0110102 



Reserved 



6.3.2.2 



New information elements used at the ISI 



6.3.2.2.1 



Call diverted to a dispatcher 



This information element shall indicate whether or not the call has been diverted to a dispatcher (as a result of the 
invocation of SS-CAD). It shall be coded as defined in table 58. 

Table 58: Call diverted to a dispatcher information element content 



Information element 


Length 


Value 


Remark 


Call diverted to a dispatcher 


1 





Call not diverted to a dispatcher 


1 


Call diverted to a dispatcher 
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6.3.2.2.2 



Call has been forward switched 



This information element shall indicate whether or not the call has already been routed by forward switching (e.g. the 
called user home SwMI is the called SwMI and the path of the call transits through that SwMI). It shall be coded as 
defined in table 59. 

Table 59: Call has been forward switched information element content 



Information element 


Length 


Value 


Remark 


Call has been forward switched 


1 





The call has not been forward switched previously 


1 


The call has been forward switched 



6.3.2.2.3 



Call identified as fleet call 



This information element shall indicate whether or not the call has been identified as a fleet call (such identification 
being made by the called user home SwMI). It shall be coded as defined in table 60. 

Table 60: Call identified as fleet call information element contents 



Information element 


Length 


Value 


Remark 


Call identified as fleet call 


1 





The call has not been identified as a fleet call 


1 


The call has been identified as a fleet call 



6.3.2.2.4 



Called/forwarded-to external subscriber number 



This information element shall be coded as defined in subclause 14.8.20 of EN 300 392-2 [1] for the air interface 
information element external subscriber number, except that its length in bits shall be equal to 4 x N, N being the value 
of the associated information element: number of digits in called/forwarded-to external subscriber number. 



6.3.2.2.5 



Called/forwarded-to party extension 



This information element shall be coded as defined in table 95 of EN 300 392-2 [1] for the air interface information 
element called party extension. 



6.3.2.2.6 



Called/forwarded-to party SSI 



This information element shall be coded as defined in table 96 of EN 300 392-2 [1] for the air interface information 
element called party SSI. 



6.3.2.2.7 



Called/forwarded-to party fleet number SSI 



This information element shall be coded as defined in table 96 of EN 300 392-2 [1] for the air interface information 
element called party SSI. 



6.3.2.2.8 



Called/forwarded-to user having migrated 



This information element shall indicate whether or not the called or the forwarded-to user, whichever applies in the case 
considered, has migrated. It shall be coded as defined in table 61. 

Table 61 : Called/forwarded-to user having migrated information element content 



Information element 


Length 


Value 


Remark 


Called/forwarded-to user having 
migrated 


1 





The called/fonwarded-to user has not migrated 


1 


The called/forwarded-to user has migrated 
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6.3.2.2.9 



Calling external subscriber number 



This information element shall be coded as defined in subclause 14.8.20 of EN 300 392-2 [1] for the air interface 
information element external subscriber number, except that its length in bits shall be equal to 4 x N, N being the value 
of the associated information element: number of digits in calling external subscriber number. 



6.3.2.2.10 



Calling external subscriber number parameters 



The meaning and the coding of this information element shall be as defined in table 21 of EN 300 392-9 [5] for the 
supplementary information element external subscriber number parameters. 



6.3.2.2.11 



Calling party fleet number SSI 



This information element shall be coded as defined in table 96 of EN 300 392-2 [1] for the air interface information 
element called party SSI. 



6.3.2.2.12 



Calling party presentation indicator 



This information element shall indicate whether or not the calling party identity can or may be presented to the called 
party through the supplementary services Calling Line Identification Presentation (SS-CLIP) or Talking Party 
Identification (SS-TPI). It shall be coded as defined in table 27 of ISO/IEC 1 1572 [16] for the presentation indicator. 

The corresponding definition of the calling party presentation indicator information element is reproduced in table 62. 
In case of discrepancy, table 27 of ISO/IEC 11572 [16] applies. 

Table 62: Calling party presentation indicator information element contents 



Information element 


Length 


Value 


Remark 


Calling party presentation indicator 


2 


OO2 


Presentation allowed 


OI2 


Presentation restricted 


IO2 


Number not available due to interworking 


II2 


Reserved 



6.3.2.2.13 



Cause for PDU addressed to originating SwMI 



This information element shall indicate the reason why the ISI-REDIRECT PDU is specifically addressed to the 
originating SwMI. Those reasons are presented in table 63, together with the definition of the corresponding coding. 

Table 63: Cause for PDU addressed to originating SwMI information element contents 



Information element 


Length 


Value 


Remark 


Cause for PDU addressed 
to originating SwMI 


3 


OOO2 


No SS-CF invoked, called user migration in originating SwMI 


001 2 


Called user barred, having migrated in originating SwMI, SS-CFU 
invoked 


01 O2 


Called user barred, having migrated in originating SwMI, SS-CFNRq 
invoked 


0112 


Reserved 


1002 


Reserved 


1012 


Reserved 


1102 


Reserved 


1112 


SS-CF invoked, SS-CF served user not barred, forwarded-to user 
not barred and having migrated in originating SwMI 



6.3.2.2.14 



Connected external subscriber number 



This information element shall be coded as defined in subclause 14.8.20 of EN 300 392-2 [1] for the air interface 
information element external subscriber number, except that its length in bits shall be equal to 4 x N, N being the value 
of the associated information element: number of digits in connected external subscriber number. 
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6.3.2.2.15 



Connected external subscriber number parameters 



The meaning and the coding of this information element shall be as defined in table 21 of EN 300 392-9 [5] for the 
supplementary information element external subscriber number parameters. 



6.3.2.2.16 



Connected party presentation indicator 



This information element shall indicate whether or not the connected party identity can or may be presented to the 
calling party through the supplementary services Connected Line identification Presentation (SS-COLP) or Talking 
Party Identification (SS-TPI). It shall be coded as defined in table 27 of ISO/IEC 11572 [16] for the presentation 
indicator. 

The corresponding definition of the connected party presentation indicator information element is reproduced in 
table 64. In case of discrepancy, table 27 of ISO/IEC 11572 [16] applies. 

Table 64: Connected party presentation indicator information element contents 



Information element 


Length 


Value 


Remark 


Connected party presentation indicator 


2 


OO2 


Presentation allowed 


OI2 


Presentation restricted 


IO2 


Number not available due to interworking 


II2 


Reserved 



6.3.2.2.17 Connected party extension 

The coding of this information element shall be the same as in table 95 of EN 300 392-2 [1]. 



6.3.2.2.18 



Connected party SSI 



This information element shall be coded as defined in table 96 of EN 300 392-2 [1] for the air interface information 
element called party SSI. 



6.3.2.2.19 



Connected party fleet number SSI 



This information element shall be coded as defined in table 96 of EN 300 392-2 [1] for the air interface information 
element called party SSI. 



6.3.2.2.20 



Controlling SwMI 



This information element shall indicate to a new SwMI involved in the call (e.g. in case of call restoration) whether or 
not it is going to be the controlling SwMI for that call (which shall be the case when the user registered in this new 
SwMI was the calling user). It shall be coded as defined in table 65. 

Table 65: Controlling SwMI information element content 



Information element 


Length 


Value 


Remark 


Controlling SwIVll 


1 





The other end SwMI is the controlling SwIVll 


1 


The new SwMI shall be the controlling SwMI 
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6.3.2.2.21 



Incoming call barring status 



This information element shall be used to inform the ANF-ISIIC entity in the terminating SwMI about the result of SS- 
BIC barring or SS-CAD authorization of the incoming call. When barred by SS-BIC the incoming call shall then be 
rejected by the ANF-ISIIC entity in the terminating SwMI unless the call is an intra-TETRA call and a local SS-BIC 
applies. This information element shall be coded as defined in table 66. 

Table 66: Incoming call barring status information element contents 



Information element 


Length 


Value 


Remark 


Incoming call barring status 


2 


OO2 


Neither SS-BIC nor SS-CAD activated 


OI2 


Call authorized by SS-CAD 


IO2 


Call barred by SS-BIC 


II2 


Call authorized by SS-BIC 



6.3.2.2.22 



Forwarded-to external subscriber number 



This information element shall be coded as defined in subclause 14.8.20 of EN 300 392-2 [1] for the air interface 
information element external subscriber number, except that its length in bits shall be equal to 4 x N, N being the value 
of the associated information element: number of digits in forwarded-to external subscriber number. 



6.3.2.2.23 



Forwarded-to user extension 



This information element shall be coded as defined in table 95 of EN 300 392-2 [1] for the air interface information 
element called party extension. 



6.3.2.2.24 



Forwarded-to user SSI 



This information element shall be coded as defined in table 96 of EN 300 392-2 [1] for the air interface information 
element called party SSI. 



6.3.2.2.25 



Last Forwarding SwMI MNI 



This information element shall be coded as defined in table 95 of EN 300 392-2 [1] for the air interface information 
element called party extension. 



6.3.2.2.26 



Modify accepted 



This information element shall indicate the modification in the simplex/duplex selection or/and the basic service 
decided by the controlling SwMI when different from that requested. It shall be coded as defined in table 112 of 
EN 300 392-2 [1] for the air interface information element modify. 



6.3.2.2.27 



Modify request 



This information element shall indicate the modification in the simplex/duplex selection or/and the basic service 
requested to the controlling SwMI. It shall be coded as defined in table 1 12 of EN 300 392-2 [1] for the air interface 
information element modify. 
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6.3.2.2.28 



MSISDN present as external subscriber number 



This information element shall indicate whether or not the related information element external subscriber number 
corresponds to an MSISDN. It shall be coded as defined in table 67. 

Table 67: MSISDN present as external subscriber number information element content 



Information element 


Length 


Value 


Remark 


MSISDN present as external 
subscriber number 


1 





The related Information element external subscriber 
number does not correspond to an MSISDN 


1 


The related information element external subscriber 
number corresponds to an MSISDN 



6.3.2.2.29 



New SwMI MNI 



This information element shall be coded as defined in table 95 of EN 300 392-2 [1] for the air interface information 
element called party extension. 

6.3.2.2.30 Number of digits in called/forwarded-to external subscriber number 

This information element shall be coded as defined in table 68. 

Table 68: Number of digits in called/forwarded-to external subscriber number length 

information element content 



Information element 


Length 


Value 


Remark 


Number of digits in called/forwarded-to external subscriber number 


5 


OOOOO2 


note 1 


> OOOOO2 


note 2 


NOTE 1 : The presence of the information element called/forwarded-to external subscriber number in TETRA PDUs 
after this information element shall be conditional on the value of this information element being different 
from 0. 

NOTE 2: The number of digits in the related information element called/forwarded-to external subscriber number 
shall be equal to N, the decimal number corresponding to the binary value XXXXX2. 



NOTE: Actually, the number of digits in called/forwarded-to external subscriber number is not an information 
element per se, but it is needed according to the PDU encoding rules defined in annex E of 
EN 300 392-2 [1], for encoding the related information element called/forwarded-to external subscriber 
number (the length of which is variable) as "a type 1 element". 



6.3.2.2.31 



Number of digits in calling external subscriber number 



This information element shall be coded as defined in subclause 6.3.2.2.30 for the information element number of digits 
in called/forwarded-to external subscriber number. The related information element shall then be the information 
element calling external subscriber number instead of the information element called/forwarded-to external subscriber 
number. 



6.3.2.2.32 



Number of digits in connected external subscriber number 



This information element shall be coded as defined in subclause 6.3.2.2.30 for the information element number of digits 
in called/forwarded-to external subscriber number. The related information element shall then be the information 
element connected external subscriber number instead of the information element called/forwarded-to external 
subscriber number. 



6.3.2.2.33 



Number of digits in forwarded-to external subscriber number 



This information element shall be coded as defined in subclause 6.3.2.2.30 for the information element number of digits 
in called/forwarded-to external subscriber number. The related information element shall then be the information 
element forwarded-to external subscriber number instead of the information element called/forwarded-to external 
subscriber number. 
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6.3.2.2.34 



Number of digits in visited/forwarded-to SwMI PISN number 



This information element shall be coded as defined in subclause 6.3.2.2.30 for the information element number of digits 
in called/forwarded-to external subscriber number. The related information element shall then be the information 
element visited/forwarded-to SwMI PISN number instead of the information element called/forwarded-to external 
subscriber number. 



6.3.2.2.35 



Originating SwMI MNI 



This information element shall be coded as defined in table 95 of EN 300 392-2 [1] for the air interface information 
element called party extension. 



6.3.2.2.36 



Other end SwMI MNI 



This information element shall be coded as defined in table 95 of EN 300 392-2 [1] for the air interface information 
element called party extension. 



6.3.2.2.37 



Override SS-CAD invocation 



This information element, used only in the ISI-SETUP PDU, shall indicate whether or not that call may bypass the 
invocation of SS-CAD. It shall be coded as defined in table 69. 

Table 69: Override SS-CAD invocation information element content 



Information element 


Length 


Value 


Remark 


Override SS-CAD invocation 


1 





No overriding of SS-CAD invocation 


1 


Overriding of SS-CAD invocation 



6.3.2.2.38 



PDU addressed to originating SwMI 



This information element shall indicate whether or not the PDU in which this information element is present is 
addressed to the originating SwMI. It shall be coded as defined in table 70. 

Table 70: PDU addressed to originating SwMI information element content 



Information element 


Length 


Value 


Remark 


PDU addressed to originating SwIVII 


1 





The PDU is not addressed to the originating SwIVII 


1 


The PDU is addressed to the originating SwMI 



6.3.2.2.39 



Possible ISI trombone or loop connection detected 



This information element shall indicate whether or not the SwMI sending the PDU in which this information element is 
present has identified that if it routed the call by forward switching, it would result in an ISI trombone or loop 
connection. This information element shall be coded as defined in table 71. 

Table 71 : Possible ISI trombone or loop connection detected information element content 



Information element 


Length 


Value 


Remark 


Possible ISI trombone or loop 
connection detected 


1 





No possible ISI trombone or loop connection resulting 
from forward switching detected 


1 


Possible ISI trombone or loop connection resulting from 
forward switching detected 



6.3.2.2.40 



Restoring party extension 



This information element shall be coded as defined in table 95 of EN 300 392-2 [1] for the air interface information 
element called party extension. 
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6.3.2.2.41 



Restoring party SSI 



This information element shall be coded as defined in table 96 of EN 300 392-2 [1] for the air interface information 
element called party SSI. 

6.3.2.2.42 Routing method choice 

This information element shall be coded as defined in table 72. 

Table 72: Routing method choice information element contents 



Information element 


Length 


Value 


Remark 


Routing method choice 


3 


OOO2 


Re-routing not supported 


001 2 


Re-routing supported, forward switching preferred 


01 O2 


Re-routing supported, the called SwMI may choose between forward 
switching and re-routing 


0112 


Re-routing supported, possible choice between forward switching and 
re-routing to be made by originating/preceding SwMI 


>01l2 


Reserved 



6.3.2.2.43 Routing method response 

This information element shall be coded as defined in table 73. 

Table 73: Routing method response information element contents 



Information element 


Length 


Value 


Remark 


Routing method response 


3 


OOO2 


Forward switching not supported 


001 2 


Forward switching supported 


01 O2 


Select re-routing 


0112 


Congestion in the SwMI sending this ISI-REDIRECT PDU 


1002 


No N X 8 kbit/s link with next SwMI (note) 


> 1002 


Reserved 


NOTE: Corresponds to the case where the ANF-ISIIC information transfer rate is equal to N x 8 kbit/s and where 
the call cannot be forwarded switched because that information transfer rate is not be available on the 
second leg of the call. 



6.3.2.2.44 



Security level at calling user air interface 



This information element is coded as defined in table 82 of EN 300 392-7 [4], the contents of which is reproduced in 
table 74. 

Table 74: Security level at calling user air interface information element contents 



Information element 


Length 


Value 


Remark 


Security level at calling user air interface 


2 


OO2 


SwMI type 1 


OI2 


SwMI type 2 


IO2 


SwMI type 3a 


II2 


SwMI type 3b 
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6.3.2.2.45 Speech service requested/chosen/used 

This information element shall be coded as defined in table 75. 

Table 75: Speech service requested/chosen/used information element contents 



Information element 


Length 


Value 


Remark 


Speech service requested/chosen/used 


3 


OOO2 


CODEC defined in ETS 300 395-2 [10] 


>0002 


Reserved 



6.3.2.2.46 



Speech services supported 



This information element is a bit-map field indicating which CODEC are supported. The meaning of each bit setting in 
this information element shall be as defined in table 76. 

Table 76: Speech services supported information element contents 



Information element 


Length 


Value 


Remark 


Speech services supported 


8 


OOOOOOOO2 


Reserved 


00000001 2 


CODEC defined in ETS 300 395-2 [10] supported 


> 00000001 2 


Reserved 



6.3.2.2.47 



SS-CF invocation counter 



The meaning and the coding of this information element shall be as defined in subclause 5.2.2.21 of 
EN 300 392-12-4 [9]. 



6.3.2.2.48 



SS-CF invoked 



This information element shall indicate whether or not SS-CF invoked has been invoked the SwMI sending the PDU in 
which this information element is present. It shall be coded as defined in table 77. 

Table 77: SS-CF invoked information element content 



Information element 


Length 


Value 


Remark 


SS-CF involved 


1 





SS-CF not invol<ed in SwIVII sending the PDU 


1 


SS-CF not invol<ed in SwIVII sending the PDU 



6.3.2.2.49 SS-CLIR invoked for other party 

This information element shall be coded as defined in table 78. 

Table 78: SS-CLIR invoked for other party information element contents 



Information element 


Length 


Value 


Remark 


SS-CLIR invoked for other party 


1 





SS-CLIR not invoked for the other party 


1 


SS-CLIR invoked for the other party 



6.3.2.2.50 



Terminating SwMI MNI 



This information element shall be coded as defined in table 95 of EN 300 392-2 [1] for the air interface information 
element called party extension. 



6.3.2.2.51 



Visited/forwarded-to SwMI MNI 



This information element shall be coded as defined in table 95 of EN 300 392-2 [1] for the air interface information 
element called party extension. 
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6.3.2.2.52 Visited/forwarded-to SwMI PISN number 

This information element shall be coded as defined in subclause 14.8.20 of EN 300 392-2 [1] for the air interface 
information element external subscriber number, except that its length in bits shall be equal to 4 x N, N being the value 
of the associated information element: number of digits in visited/forwarded-to SwMI PISN number. 

6.3.3 PSS1 facility information element 

The ROSE operation tetralsiMessage referred to in subclause 6.3.1 shall be coded in PSSl facility information elements 
in accordance with ISO/IEC 1 1582 [18]. Each such facility information elements shall always include a Network 
Facility Extension (NEE). 

The destinationEntity and sourceEntity data elements of the Network Facility Extension (NFE) shall contain the value 
endPINX except in two following specific cases where the call is an inter-TETRA call established with at least one 
forward switching operation: 

one of the two users engaged in this call migrates and registers in a SwMI which the old SwMI for that migrating 
user identifies as being on the path of the call (i.e. the call has been forward switched in that new SwMI); the old 
SwMI will then want to address the ISI-PATH RESTORE PREPARE PDU, defined in table 48, to that new 
SWMI; 

- SS-CF has been invoked and the ISI-REDIRECT PDU, defined in table 28, has to be sent to the preceding SwMI 
(i.e. the last forwarding SwMI on the path of the call), and not to the originating SwMI. 

In each of the above cases, the destinationEntity data element of the Network Facility Extension (NFE) of the PSSI 
facility information element (in the PSSl FACILITY message) conveying the ROSE operation tetralsiMessage 
including the ISI-PATH RESTORE PREPARE PDU or the ISI-REDIRECT PDU shall contain the value 
anyTypeOfPINX with a destinationEntity Address containing a PISN number corresponding to the new SwMI or to the 
last forward switching on the path of the call. That PISN number shall be either: 

that delivered by ANF-ISIMM (e.g. the SwMI on the path of the call is the home SwMI of the connected user 
and the PISN number to use that user -while registered in that SwMI- has been delivered by ANF-ISIMM - such 
delivery being an ANF-ISIMM option); or 

that determined by the SwMI sending the above TETRA PDU as corresponding to the destination SwMI in its 
routing table. 

The sourceEntity and destinationEntity data elements of the argument of the ROSE operation tetralsiMessage shall 
contain the value ANF-ISIIC. 

Whenever the ANF-ISIIC Invoke APDU of the ROSE operation tetralsiMessage is included in a PSSl SETUP 
message, the Interpretation APDU shall be included with the value "clearCalllfAnylnvokePduNotRecognised". 

NOTE: According to subclause 8.6 of ETS 300 392-3-1 [2], if the called SwMI or the terminating SwMI do not 
support inter-TETRA individual calls, i.e. they do not have an ANF-ISIIC entity, when it receives a PSSl 
SETUP message addressed to this entity such SwMI: 

will have its ROSE entity rejecting the ROSE Invoke APDU received; and 

will clear the PSSl call attempt due to the specific value of the Interpretation APDU received together 
with the ROSE Invoke APDU. 

The same will hold if the new SwMI in the call restoration procedure (see subclause 6.5.2.3) does not 
support inter-TETRA individual calls. 

No Interpretation APDU shall be included together with any of the ANF-ISIIC Invoke APDUs of the ROSE operation 
tetralsiMessage included in other PSSl messages than SETUP messages. 

In accordance with ETS 300 392-3-1 [2] subclause 8.4, the ISI entity concerned in the destination SwMI will trigger the 
sending of a returnError APDU when one or more of the error causes listed in this subclause has occurred in the 
reception of an Invoke APDU. 
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Among those error causes, the cause corresponding to requestNotSupported (see subclause 8.4 of ETS 300 392-3-1 [2]) 
may only apply when a specific ANF-ISIIC request is not supported. The cases where this may happen are: 

if the called user has migrated, if its home SwMI is the called SwMI and if the originating and the called SwMIs 
cannot agree on the routing method to be used: forward switching versus re-routing (see table 67); 

if one of the two parties migrates during an individual call and registers in a new SwMI which supports 
individual calls but not call restoration (see subclause 6.5.2.3). 

When the ROSE entity in the source SwMI receives this returnError APDU or a reject APDU, it shall pass it to the call 
control application in this SwMI. The decision taken by this call control application when the destination SwMI has not 
already cleared the call is an implementation matter (e.g. clearing the call or if the Invoke APDU was not essential, 
continue the call). 

6.4 ANF-ISIIC state definitions 

NOTE: These states correspond to both the PINX protocol control states for circuit-mode call, defined in 

subclause 7.1 of ISO/IEC 11572 [16], and the SwMI protocol control states for individual (circuit-mode) 
call. The SwMI protocol states have not been explicitly standardized in EN 300 392-2 [1]. 

6.5 ANF-ISIIC signalling procedures 

The signalling procedures below specify the conditions under which the SwMI ANF-ISIIC entities send or receive: 

- the TETRA ISI PDUs defined in subclause 6.3.1; and 

PISN basic call primitives together with some of these TETRA PDUs. 

The specific parameters of some of those primitives have been defined in subclause 6.2. 

To simplify the text below, only the results of those PISN basic call primitives have been specified, e.g. sending of a 
PSSl SETUP or CONNECT message. 

NOTE: From a formal point of view the SwMI PSSl protocol control entities are not part of the ANF-ISIIC 
entities. 

6.5.1 Call establishment 

6.5.1 .1 Call request, information channel selection, PISN called number sending and 
call proceeding 

Call establishment shall be initiated by a primitive sent by the CC entity to the ANF-ISIIC entity in the originating 
SwMI. This ANF-ISIIC entity shall then send the PSSl SETUP message defined in subclause 6.2.1 including the 
ISI-SETUP PDU, defined in table 26. 

The procedures defined in ISO/IEC 1 1572 [16] for information channel selection, called number sending, call 
proceeding shall apply. En bloc sending method should be used but overlap sending method is not ruled out. 

6.5.1 .2 Called user migration 

When the home SwMI of the called user is different from the originating SwMI (SwMI A), i.e. the called user home 
SwMI is SwMI B, and that user has migrated, two different cases arise depending on whether that user has migrated 
into a third SwMI (SwMI C, different from SwMI A) or into SwMI A (i.e. SwMI C coincides with SwMI A). 



ETSI 



1 04 ETSI TS 1 00 392-3-2 V1 .1 .1 (2000-1 0) 

6.5.1 .2.1 Called user having migrated in SwMI C different from SwMI A 

If the called user has migrated into a third SwMI (SwMI C, different from SwMI A) and SwMI B has decided to 
continue the establishment of the call unless it cannot route it, the following shall apply to SwMI B, depending of the 
value of the information element routing method choice, defined in table 72, in the ISI-SETUP PDU received from 
SwMI A: 

a) if the value of that information element routing method choice corresponds to re-routing not supported (by 
SwMI A): 

if SwMI B supports forward switching and has decided to continue the establishment of the call in routing it 
by forward switching, it shall send to SwMI C the ISI-SETUP PDU, defined in table 26. Except possibly for 
the value of the call priority information element (to be used according to the specifications of the 
supplementary services priority call and pre-emptive priority call), the values of the information elements of 
that ISI-SETUP PDU shall be identical to those in the ISI-SETUP PDU received from SwMI A except for the 
following ones (see note 1): 

the value of the information element call has been forward switched shall indicate that the call has been 
forward switched; 

- the value of the information element last forwarding SwMI MNI (conditional on the value of the 
preceding information element indicating that the call has been forward switched) shall be equal to 
SwMI B MNI (which in that case will also be equal to the value of the information element called party 
extension); 

the value of the information elements simplex/duplex selection and/or basic service information may be 
changed by SwMI B (home SwMI of the called user) if it knows that the called user does not support 
those in the ISI-SETUP PDU received from SwMI A. If SwMI B changes one of those values, it should 
inform SwMI A about that change in sending a PSSl FACILITY message (see note 2) including the 
ISI-CALL PROCEEDING PDU, defined in table 32 (see note 3); 

in addition, if as an option SwMI B supports fleet calling and if it finds out that the value information 
element called/forwarded-to party SSI in the ISI-SETUP PDU which it has received from the originating 
SwMI corresponds actually to a fleet call, the value of the information element called/forwarded-to party 
SSI shall be the actual SSI of the called/forwarded-to party, while the information element 
called/forwarded-to party fleet number SSI shall be present with the value of the information element 
called/forwarded-to party SSI in the ISI-SETUP PDU received from the originating SwMI (corresponding 
to the fleet number of the called/forwarded-to party). In addition the information element calling party 
fleet number SSI shall be present with a value equal to the fleet number SSI of the calling party; 



or 



if SwMI B cannot route the call because it does not support forward switching (therefore cannot continue the 
establishment of the call) or because of congestion (whether internal or by lack of free ISI connection 
towards SwMI C), it shall send a PSSl FACILITY message (see note 2) including the ISI-REDIRECT PDU, 
defined in table 28. The values of the information elements of that PDU shall be as follows: 

the value of the information element "possible ISI trombone or loop connection detected" shall indicate 
that SwMI B has not identified that SwMI C coincides with SwMI A; 

the value of the information element visited/forwarded-to SwMI MNI shall be equal to SwMI C MNI and 
the values of those on the PISN number of the visited/forwarded-to SwMI shall give the SwMI C PISN 
number to be used for routing calls to the called user in SwMI C (see note 4); 

the value of the information element routing method response (see table 73) shall correspond to: 

forward switching not supported, if SwMI B does not support forward switching; or 

- congestion in the SwMI sending this ISI-REDIRECT PDU; 

the value of the information element SS-CF invocation counter shall be the same as that in the 
ISI-SETUP PDU received from SwMI A, and the value of the information element SS-CF information 
present shall indicate that no such information is present (see note 1); 
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if the information element notification indicator is present, its value shall correspond to a notification 
addressed to the called user (and not to the calling user); 

in addition, if as an option SwMI B supports fleet calling and if it finds out that the value information 
element called/forwarded-to party SSI in the ISI-SETUP PDU which it has received from the originating 
SwMI corresponds actually to a fleet call, the value of the information element called/forwarded-to party 
SSI shall be the actual SSI of the called/forwarded-to party, while the information element 
called/forwarded-to party fleet number SSI shall be present with the value of the information element 
called/forwarded-to party SSI in the ISI-SETUP PDU received from the originating SwMI (corresponding 
to the fleet number of the called/forwarded-to party). In addition the information element calling party 
fleet number SSI shall be present with a value equal to the fleet number SSI of the calling party; 

b) if the value of that information element routing method choice corresponds to either "re-routing supported (by 
SwMI A), forward switching (by SwMI B) preferred" or "re-routing supported (by SwMI A), the called SwMI 
(i.e. SwMI B) may choose between forward switching and re-routing": 

if SwMI B supports forward switching and has decided to continue the establishment of the call in forward 
switching it, it shall send to SwMI C the PSSl SETUP message including ISI-SETUP PDU, defined in 
table 26. The specification of the values of the information elements of that ISI-SETUP PDU shall be the 
same as in case a) above (for the same PDU sent by SwMI B - to SwMI C); 

or 

if SwMI B either does not support forward switching or has decided not to forward switch the call, it shall 
send to SwMI A a PSSl FACILITY message (see note 2) including the ISI-REDIRECT PDU, defined in 
table 28. The specification of the values of the information elements of that ISI- REDIRECT PDU shall be 
the same as in case a) above, except that the value of the information element routing method response shall 
correspond to "forward switching not supported" if SwMI B does not support forward switching or to "select 
re-routing" if it supports forward switching but has decided not to forward switch the present call (instead of 
"forward switching not supported" or "congestion in the SwMI sending this ISI-REDIRECT PDU" in case a) 
above); 

c) if the value of that information element routing method choice corresponds to re-routing supported (by 

SwMI A), possible choice between forward switching and re-routing to be made by originating/preceding SwMI 
(i.e. SwMI A), SwMI B shall send to SwMI A a PSSl FACILITY message (see note 2) including the 
ISI-REDIRECT PDU, defined in table 28. The specification of the values of the information elements of that 
PDU shall be the same as in case a) above (for the same ISI-REDIRECT PDU sent by SwMI B), except that the 
value of the information element routing method response shall correspond to forward switching supported or to 
forward switching not supported, depending on whether SwMI B supports forward switching or not (instead of 
forward switching not supported or select re-routing in case b) above). 

NOTE 1 : The case of invocation of a call forwarding supplementary service in SwMI B (i.e. for the called user) is 
excluded in the present subclause 6.5 (see subclause 6.7 for such a case). 

NOTE 2: The sending of the ISI-CALL PROCEEDING to SwMI A is compulsory in such a case because otherwise 
SwMI A would not be informed about the call modification - since SwMI C, the terminating SwMI, will 
itself not be aware of it. 

NOTE 3: According to the PSSl procedures for sending PSSl FACILITY messages backwards, such messages will 
only be sent after the PSSl CALL PROCEEDING message has been sent. 

NOTE 4: According to ETS 300 392-3-5 [3], the visited SwMI MNI will be delivered to SwMI B, the home SwMI 
of the migrating called user, from SwMI C, his visited SwMI, by ANF-ISIMM as part of the migration 
information for that user. In addition SwMI C may send, also as part of the migration information 
delivered by ANF-ISIMM, the PISN number (in the range of PISN numbers allocated to that SwMI) to be 
used for routing calls to the called user in that SwMI. If such PISN number is not delivered by 
ANF-ISIMM, then the old SwMI will use the PISN number corresponding to the new SwMI MNI in its 
routing table. 
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If SwMI A has received the PSSl FACILITY message including the ISI-REDIRECT PDU, depending on the value of 
the information element routing method response in that PDU, it shall decide either to re-route the call or to have it 
forward switched (see note 5), towards SwMI C: 

if SwMI A decides to have the call forward switched, it shall send to the called SwMI the 
ISI-FORWARD SWITCH PDU defined in table 29 in a PSSl FACILITY message. The called SwMI shall then 
send to the visited SwMI the PSSl SETUP message including the ISI-SETUP PDU defined in table 26. The 
specification of the values of the information elements of that ISI-SETUP PDU shall be the same as in case a) 
above (for the same PDU sent by SwMI B - to SwMI C); 

if SwMI A decides to re-route the call, it shall: 

initiate a new call establishment (see subclause 6.5.1.1) in sending the PSSl SETUP message including 
ISI-SETUP PDU, defined in table 26. The values of the information elements of that ISI-SETUP PDU shall 
be the same as those in the ISI-SETUP PDU sent previously to SwMI B except possibly for the values (see 
note 1 above): 

of the call priority information element (to be used according to the specifications of the supplementary 
services priority call and pre-emptive priority call); 

of the information element routing method choice, which shall correspond to SwMI A routing method 
choice (now related to its ISI connection with SwMI C) if further routing of the call by the invoked 
ANF-ISIIC was necessary because a call forwarding supplementary service has be invoked for the called 
user in SwMI C (not SS-CFU since SwMI C is the called user visited SwMI, but e.g. SS-CFU or 
SS-CFNRy); and/or 

of the (optional) information element notification indicator, which shall be equal to that of the same 
information element received in the corresponding ISI-REDIRECT PDU. If that PDU did not include the 
information element notification indicator, the new ISI-SETUP PDU shall not include it either; 

and 

- send a PSSl DISCONNECT message including the ISI-DISCONNECT PDU, defined in table 51, to clear 
the ISI connection between SwMI A and SwMI B previously seized by the invoked ANF-ISIIC, which has 
become unnecessary. In that PDU, the value of the information element disconnect cause, defined in table 56, 
shall correspond to call re-routed. 

NOTE 5: While in theory nothing prevents SwMI A to decide to have the call forward switched (by SwMI B) if the 
value of the information element routing method response in the ISI-REDIRECT PDU which it has 
received corresponds to select re-routing (see case b) above), SwMI A should avoid it, since otherwise 
SwMI B could very well reject the corresponding request. 

If the value of the information element routing method response in the ISI-REDIRECT PDU is inconsistent with that of 
the information element routing method in the corresponding ISI-SETUP PDU (e.g. SwMI A has indicated that it does 
not support re-routing and SwMI B has responded in requesting SwMI A to select re-routing, SwMI A shall send the 
PSSl DISCONNECT message including the ROSE Return Error APDU with the cause corresponding to 
requestNotSupported (see subclause 6.3.3) - thus clearing the ISI connection between SwMI A and SwMI B previously 
seized by the invoked ANF-ISIIC. 

If the value of the information element routing method response in the ISI-REDIRECT PDU is consistent with that of 
the information element routing method in the corresponding ISI-SETUP PDU but does not allow SwMI A to continue 
the establishment of the call (e.g. SwMI A has indicated that it does not support re-routing and SwMI B has responded 
in indicating that it does not support forward switching or that it cannot forward switch the call due to congestion), 
SwMI A shall simply send the PSSl DISCONNECT message including the ISI-DISCONNECT PDU, defined in 
table 5 1 . In that PDU, the value of the information element disconnect cause, defined in table 56, should correspond to 
no possible routing of the call. 
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6.5.1 .2.2 Called user having migrated in SwMI C coinciding with SwMI A 

If the called user has migrated into SwMI A (i.e. SwMI C coincides with SwMI A), this shall be identified by SwMI B 
if it has received the ISI-SETUP PDU from SwMI A (see note 1 below). SwMI B shall then send to SwMI A a 
FACILITY message including the ISI-REDIRECT PDU defined in table 28. The values of the information elements of 
that PDU shall be as follows: 

the value of both information elements "possible ISI trombone or loop connection detected" and "PDU addressed 
to originating SwMI" shall indicate that SwMI B has identified that SwMI C coincides with SwMI A, thereby 
forcing the call to be established as an intra-TETRA call (see note 1 below); 

the value of the information element SS-CF invocation counter shall be the same as that in the ISI-SETUP PDU 
received from SwMI A, and the value of the information element SS-CF information present shall indicate that 
no such information is present (see note 2 below); 

the value of the information element incoming call barring status (see note 3 below) shall indicate that neither 
the supplementary service barring of incoming calls nor that of call authorized by dispatcher for the called user 
have been activated; 

in addition, if as an option SwMI B supports fleet calling and if it finds out that the value information element 
called/forwarded-to party SSI in the ISI-SETUP PDU which it has received from the originating SwMI 
corresponds actually to a fleet call, the value of the information element called/forwarded-to party SSI shall be 
the actual SSI of the called/forwarded-to party, while the information element called/forwarded-to party fleet 
number SSI shall be present with the value of the information element called/forwarded-to party SSI in the 
ISI-SETUP PDU received from the originating SwMI (corresponding to the fleet number of the 
called/forwarded-to party). In addition the information element calling party fleet number SSI shall be present 
with a value equal to the fleet number SSI of the calling party. 

NOTE 1 : SwMI A may of course detect by itself (i.e. without the need to send the ISI-SETUP PDU to SwMI B and 
to receive back the ISI-REDIRECT PDU) that the called user is currently registered in that SwMI (after 
having migrated from SwMI B). However this is not mandatory. Furthermore, SwMI A cannot detect 
such case e.g. when the calling party addresses the called user using his MSISDN or his fleet number. 

NOTE 2: The case of invocation of a call forwarding supplementary service in SwMI B (i.e. for the called user) is 
excluded in the present subclause 6.5 (see subclause 6.7 for such a case). 

NOTE 3: The case of invocation of the supplementary services barring of incoming calls or call authorized by 

dispatcher for the called user is excluded in the present subclause 6.5 (see subclause 6.7 for such cases). 

6.5.1 .3 Call characteristics and set-up time negotiation by the terminating SwMI 

The terminating SwMI may indicate to the originating SwMI its fallback choice for some characteristics requested for 
the call in the PSSl SETUP message that it cannot support (i.e. duplex selection, N slot bearer requested for a data call 
in the basic service information element, speech service) in sending the ISI-CALL PROCEEDING PDU, defined in 
table 32, else the ISI-INFO DEMAND PDU, defined in table 40, in a PSSl FACILITY message. Note that contrary to 
the ISI-INFO DEMAND PDU, the ISI-CALL PROCEEDING PDU includes the information element call time-out, 
set-up time, defined in subclause 6.3.2.1.3, which allows the terminating SwMI to inform the originating one about its 
call time-out in the set-up phase. 

Instead of a FACILITY message including this ISI-CALL PROCEEDING PDU, the terminating SwMI may send a 
PSSl FACILITY message including the ISI-SETUP PROLONGATION PDU, defined in table 33, if it only wants to 
inform the originating SwMI about its call time-out in the set-up phase (a priori, because it wants to have it modified). 
This shall hold until the terminating SwMI has received a PSSl FACILITY message including the 
ISI-CONNECT ACKNOWLEDGE PDU, defined in table 34 (see subclause 6.5.1.4 below). 

NOTE 1 : Hopefully, this call time-out in the set-up phase should be greater than or equal to that indicated by the 
originating SwMI in its PSSl SETUP message. 

Upon receiving this message, the originating SwMI call control application should ensure that the air interface CC 
entity extends its timer T302 (see table 58 of EN 300 392-2 [1], and the ANF-ISIIC entity should extend PSSl timer 
T310 (see table 4 of ISO/IEC 11572 [16]), if necessary. If the call has been forward switched, by the called SwMI, the 
same should apply to the called SwMI. 
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NOTE 2: If PS SI timer T310 is implemented in transit PINXs between the originating and the terminating SwMIs 
which are not part of the forward switching (called) SwMI, it will not be extended by this message. 

NOTE 3: According to the PSSl procedures for sending (PSSl) FACILITY backwards, such message will only be 
sent after the (PSSl) CALL PROCEEDING message has been sent. 

After having received one of the above PSSl FACILITY messages informing it about the terminating SwMI call time- 
out in the set-up phase, the originating SwMI may send a PSSl FACILITY message including the ISI-SETUP 
PROLONGATION PDU, defined in table 33, if it wants to inform the terminating SwMI about its call time-out in the 
set-up phase. This shall hold until the originating SwMI has sent a PSSl FACILITY message including the 
ISI-CONNECT ACKNOWLEDGE PDU, defined in table 34 (see subclause 6.5.1.4 below). 

NOTE 4: Having received a PSSl FACILITY message from the terminating SwMI ensures that a signalling path 
exists with this SwMI. 

6.5.1 .4 Call confirmation indication and call connected by the terminating SwMI 

The procedures defined in ISO/IEC 1 1572 [16] for call confirmation indication and call connected shall apply. 

If the terminating SwMI is instructed by the called user air interface U- ALERT PDU to use on/off hook signalling, it 
shall send the PSSl ALERTING message including the ISI-ALERTING PDU, defined in table 30. If it is instructed by 
the called user air interface U-CONNECT PDU to use direct call set-up signalling, it shall send the PSSl CONNECT 
message including the ISI-CONNECT PDU, defined in table 31. 

The terminating SwMI may use either of these PDUs to indicate to the originating SwMI its fallback choice for some 
characteristics that it cannot support (i.e. duplex selection, N slot bearer requested for a data call in the basic service 
information element and speech service; in addition, hook method selection but only in the PSSl CONNECT message) 
among those requested for the call in the SETUP PDU received by this SwMI. Once such fallback choices shall have 
been indicated in a PSSl message, they shall not be repeated in the next ones, i.e. the PSSl ALERTING message for 
the PSSl CONNECT message in the case of on/off hook signalling, and possibly a PSS 1 FACILITY message 
(including the ISI-CALL PROCEEDING PDU, defined in table 32, else the ISI-INFO DEMAND PDU, defined in 
table 40) for the PSSl ALERTING or CONNECT messages. 

The terminating SwMI shall include the information element connected party fleet number SSI in that ISI-CONNECT 
PDU whenever the ISI-SETUP PDU, defined in table 26, which it has received included the information element 
called/forwarded-to party fleet number SSI (independently of whether or not the terminating SwMI supports fleet 
calling). The value of that information element connected party fleet number SSI shall be equal to that of the 
information element called/forwarded-to party fleet number SSI received. 

To confirm that the call has actually been established on the calling user side, the originating SwMI shall acknowledge 
the PSSl CONNECT message in sending to the terminating SwMI a PSSl FACILITY including the 
ISI-CONNECT ACKNOWLEDGE PDU, defined in table 34. 

6.5.1 .5 Failure of call establishment 

If the call attempt is rejected by the terminating SwMI (because of e.g. incompatibility between the security levels at the 
calling and the called air interfaces, or internal congestion), by the called user (because e.g. it is busy, or end-to-end 
encryption was requested in the set-up and this user does not support it) or by the called SwMI when it is not the 
terminating SwMI, i.e. the called user has migrated, (because of e.g. unassigned number), the SwMI rejecting this call 
(or relaying the called user rejection) shall send a PSSl DISCONNECT message including the 
ISI-DISCONNECT PDU, defined in table 51, with the appropriate disconnect cause. 

The same shall apply if the terminating SwMI or, when it is not the terminating SwMI, the called SwMI rejects the call 
attempt in sending the PSSl RELEASE COMPLETE message (see exception conditions defined in subclause 10.2.2 of 
ISO/IEC 1 1572 [16] for the call clearing PSSl protocol). 

In addition, the establishment of the call may fail for a reason related only to the PSSl procedure (i.e. not to 
ANF-ISIIC), e.g. no circuit channel available. The procedure defined in ISO/IEC 11572 [16] for failure of call 
establishment shall then apply. The inclusion of the ISI-DISCONNECT PDU, defined in table 51, in the corresponding 
PSSl DISCONNECT or RELEASE COMPLETE message is then an implementation matter. 
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6.5.2 Call maintenance procedures 

6.5.2.1 Transmission control procedures 

As already stated in the stage 1 description, the originating SwMI shall be the controlling one. Consequently, it shall 
send to the terminating SwMI a PSSl FACILITY message for every D-TX PDU to be sent by the latter to the called 
user. Each such PSSl FACILITY message shall include a TETRA PDU corresponding to the relevant D-TX message. 
These TETRA PDUs are defined in tables 35, 36, 37, 38 and 39. 

If the originating SwMI decides to interrupt the call (in sending the air interface of D-TX WAIT PDU to the calling 
user), it shall then send a PSSl FACILITY message including the ISI-TX WAIT PDU defined in table 39. 

The terminating SwMI shall relay to the originating SwMI the air interface U-TX PDUs that it receives to request 
transmission grant or inform that transmission has ceased, by sending a PSSl FACILITY message including the 
TETRA PDUs defined in tables 42 and 43, respectively. After the terminating SwMI has interrupted the call, to request 
to the originating SwMI the authorization to continue the call it shall send a PSSl FACILITY message including the 
ISI-TX CONTINUE PDU defined in table 44. 

6.5.2.2 Call modification and/or continuation 

To inform the other end SwMI that it wants to change the call time-out, the originating or the terminating SwMI shall 
send a PSSl FACILITY message including the ISI-INFO DEMAND PDU defined in table 40. 

NOTE 1: This SwMI should then wait for receiving an agreement from the other end SwMI before requesting the 
user that it is controlling to start timer T310 using this new call time-out value. 

The same PSSl FACILITY message can also be used to request from the other end some call modification (as specified 
in subclause 14.5.1.2 of EN 300 392-2 [1]). The call time-out information element included in this TETRA PDU shall 
then be related to the modification requested. 

Upon receiving the PSSl FACILITY message including the ISI-INFO DEMAND PDU, the other end SwMI shall send 
a PSSl FACILITY message including the ISI-INFO REPLY PDU defined in table 41. 

NOTE 2: According to the negotiation clauses for incoming call in subclause 14.5.1.1 of EN 300 392-2 [1] and to 
the definition of the class of MS (information) element in table 167 of EN 300 392-2 [1], possibly 
supplemented by information transferred by ANF-ISIMM, this other SwMI should always know whether 
the user that it controls would support the requested changes. This holds notably if the other user has 
requested a change (from simplex operation) to duplex operation or (from clear call) to encrypted call, 
which is possible according to subclause 14.5.1.2 of EN 300 392-2 [1]. 

6.5.2.3 Call restoration 

6.5.2.3.1 General call restoration procedure 

6.5.2.3.1 .1 Start of general call restoration procedure 

When during an established (individual) inter-TETRA call, the call control application in the originating or in the 
terminating SwMI receives the information (from ANF-ISIMM) that the user (participating in the call) which was 
registered in the SwMI has migrated and is now registered in a new SwMI, the ANF-ISIIC entity invoked for that call 
should send a PSSl SETUP message including the ISI-CALL RESTORE PREPARE PDU defined in table 45. 

Similarly, in the case of migration of one of the two users involved in an intra-TETRA call established within a given 
SwMI, this SwMI should send to the new SwMI a PSSl SETUP message including the same ISI-CALL RESTORE 
PREPARE PDU, defined in table 45. 

NOTE: Formally, the SwMI call control application invokes then an ANF-ISIIC. It is that invoked ANF-ISIIC 
which triggers that PSSl SETUP message. 

In the procedure described below, the originating or terminating SwMI which sent the SETUP message as defined in 
either of the two preceding paragraphs shall be called the old SwMI. 

At the same time that it sends the PSSl SETUP message, the old SwMI shall start timer Tl. 
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6.5.2.3.1 .2 Successful general call restoration 

After the new SwMI has received the PSSl SETUP message including the same ISI-CALL RESTORE 
PREPARE PDU, to indicate that it accepts to continue the ANF-ISIIC general call restoration procedure, it shall send a 
PSSl CONNECT message including the ISI-CALL RESTORE PREPARED PDU, defined in table 46, if it has not yet 
received the call restoration message from its new visiting user, or the ISI-CALL RESTORATION PDU, defined in 
table 47, if it has received the call restoration message from its new visiting user in time. 

If call restoration (by the migrating user) has occurred after the new SwMI has sent the PSSl CONNECT message, it 
shall send the ISI-CALL RESTORATION PDU, defined in table 47, in a PSSl FACILITY message. 

When the old SwMI receives that ISI-CALL RESTORATION PDU (whether in a PSSl CONNECT or FACILITY 
message) it shall transfer the call (by join), relay that PDU to the other end SwMI (in a PSSl FACILITY message) and 
stop timer Tl. 

If the other end SwMI is itself engaged in an ANF-ISIIC call restoration procedure, it shall relay that ISI-CALL 
RESTORATION PDU to the new SwMI for that procedure. 

6.5.2.3.1 .3 Failures cases of the general call restoration procedure 

If no ISI connection can be established between the old SwMI and the new SwMI, the procedure defined in 
ISO/IEC 1 1572 [16] for failure of call establishment shall then apply. No TETRA PDU needs to be included in the 
corresponding PSSl DISCONNECT or RELEASE COMPLETE message. 

If the new SwMI does not support the ANF-ISIIC call restoration procedure (whether because it does not support call 
restoration at all, or only the ANF-ISIIC call restoration procedure), it shall send to the old SwMI a PSSl FACILITY 
message including the ROSE Return Error APDU with the cause corresponding to requestNotSupported (see 
subclause 6.3.3) in one of the following PSSl messages clearing the ISI connection seized between the old and the new 
SwMIs either: 

a PSSl RELEASE COMPLETE message if the corresponding exception condition defined in subclause 10.2.2 
of ISO/IEC 11572 [16] applies; or 

- a PSS 1 DISCONNECT message. 

NOTE: See note in subclause 6.3.3 if the new SwMI does not support ANF-ISIIC. 

The old SwMI would then send the ISI-DISCONNECT PDU to the other end SwMI with the (ISI) disconnect cause: 
"ANF-ISIIC call restoration procedure not supported in new SwMI", possibly after having waited for a few seconds to 
send that message - the purpose of that delay is to keep the ISI connection in case the user who has migrated into the 
new SwMI would migrate back into the old SwMI very soon. 

If the new SwMI supports the ANF-ISIIC call restoration procedure (which entails that it supports the air interface call 
restoration procedure) but decides to reject the set-up from the old SwMI for any other reason (because e.g. its air 
interface security level cannot match that used at calling user air interface), it shall send the same 
ISI-DISCONNECT PDU, defined in table 51, in clearing the ISI connection seized between the old and the new 
SwMIs. The value of the disconnect cause in that ISI-DISCONNECT PDU should indicate the other reason why the 
new SwMI has decided to reject the set-up from the old SwMI. 

Upon expiry of timer Tl (i.e. because it has not received the ISI-CALL RESTORATION PDU before), the old SwMI 
shall release the ISI connection with the new SwMI that it had seized, in sending a PSSl DISCONNECT message to 
that SwMI. 

6.5.2.3.2 Specific call restoration procedure in a SwMI already on the path of the call 

The following procedure is recommended instead of the general one specified in subclause 6.5.2.3.1 above in the 
special cases where the new SwMI coincides with a SwMI already on the path of the call, i.e. when no call forwarding 
supplementary service is invoked: either the forward switching SwMI if the call has been forward switched or the other 
end SwMI (terminating or originating SwMI). 
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6.5.2.3.2.1 Start of specific call restoration procedure 

If an inter-TETRA call has been forward switched (i.e. when no call forwarding supplementary service is invoked: by 
the called user home SwMI), if migration of one of the two users engaged in that call occurs and if the new SwMI 
coincides with the forward switching SwMI, the old SwMI ANF-ISIIC entity should detect this and should then send to 
the forward switching/new SwMI a PSSl FACILITY message including the ISI-PATH CALL RESTORE 
PREPARE PDU, defined in table 48. 

Similarly, if instead of coinciding with the forward switching SwMI, the new SwMI coincides with the other end SwMI, 
the old SwMI ANF-ISIIC entity should detect this and should then send to the other end/new SwMI a PSSl FACILITY 
message including the ISI-END CALL RESTORE PREPARE PDU, defined in table 49, unless it has already received 
the ISI-SIMULTANEOUS MIGRATION PDU as provided in the next paragraph. 

NOTE 1 : Clearly, the possibility of trombone (or more generally loop) connection is excluded in the case of 
migration of one of the two users involved in an established intra-TETRA call. 

Still when the new SwMI coincides with the other end SwMI, the following shall apply if the other user migrates 
himself into a SwMI already on the path of the call after the first user (i.e. the user for whom the new SwMI has 
received the ISI-END CALL RESTORE PREPARE PDU) but before that first user has restored his side of the call and: 

if the SwMI into which the other user migrates is a SwMI through which the call has been forward switched and 
the new SwMI can identify it, that new SwMI shall send the ISI-SIMULTANEOUS MIGRATION PDU, defined 
in table 50, to the forward switching SwMI together with the ISI-PATH CALL RESTORE PREPARE PDU (i.e. 
in the same PSSl FACILITY message). That case is shown as case a.l in figure 23; 

if the SwMI into which the other user migrates is the old SwMI (i.e. the two users switch the SwMIs where they 
were previously registered), the new SwMI shall not send the ISI-END CALL RESTORE PREPARE PDU to 
the old SwMI for the other user migration but shall send instead a PSSl FACILITY message including the 
ISI-SIMULTANEOUS MIGRATION PDU, defined in table 50. That case is shown as case a.2 in figure 23. 

NOTE 2: The last indented paragraph means that when both users switch at about the same time the SwMIs where 
they were previously registered and this is identified by those SwMIs, the SwMI which is the first to 
identify the situation will not send the ISI-END CALL RESTORE PREPARE PDU but the 
ISI-SIMULTANEOUS MIGRATION PDU. 

If one user migrates first into a SwMI through which the call has been forward switched, if the (end) SwMI where he 
was registered can identify it and if the other user migrates himself into that end SwMI after the first user but before that 
first user has restored his side of the call, that end SwMI shall send a PSSl FACILITY message including the 
ISI-SIMULTANEOUS MIGRATION PDU, defined in table 50, to the SwMI where the first user has migrated (i.e. a 
SwMI through which the call has been forward switched). That case is shown as case b in figure 23. 

NOTE 3: No need has been found to require the sending of a specific PDU if both users migrate at around the same 
time each into a SwMI through which the call has been forward switched and both the originating and the 
terminating SwMIs can identify it, because either: 

that SwMI will be the same for both users; or 

if both SwMIs are different, the only SwMI through which the call has been forward switched that the 
ANF-ISIIC routing procedure allows the originating SwMI to identify is the SwMI where the call has 
been forward switched for the first time, while for the terminating SwMI, it is the SwMI where the 
call has been forward switched for the first time. Consequently if the calling user migrates into that 
SwMI where the call has been forward switched for the first time, the clearing of the ISI connection 
between that SwMI and the originating SwMI, which is the main part of the successful call restoration 
as defined in the following subclause, will be independent of whether or not the connected user is also 
migrating into that SwMI where the call has been forward switched for the last time; the same 
consideration will equally apply for the clearing of the ISI connection between the SwMI that SwMI 
where the call has been forward switched for the last time and the terminating SwMI. 
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Figure 23: Simultaneous migration into SwIUIIs already on the path of the call 
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6.5.2.3.2.2 Successful specific call restoration 

After the new SwMI has received the ISI-PATH CALL RESTORE PREPARE PDU or the ISI-END CALL RESTORE 
PREPARE PDU, if it accepts to continue the corresponding ANF-ISIIC specific call restoration procedure, it shall send 
back to the old SwMI a PSSl FACILITY message including the ISI-CALL RESTORE PREPARED PDU, defined in 
table 46, unless it has already successfully restored the call for its new visiting user in which case it shall send back to 
the old SwMI a PSSl FACILITY message including the ISI-CALL RESTORATION PDU, defined in table 47. 

If the new SwMI is a SwMI through which the call has been forward switched (i.e. it has received the ISI-PATH CALL 
RESTORE PREPARE PDU from the old SwMI), it shall send a PSSl FACILITY message including the ISI-CALL 
RESTORATION PDU, defined in table 47, after it has successfully restored the call for its new visiting user: 

- to the other end SwMI than the old SwMI if it has not received the ISI-SIMULTANEOUS MIGRATION PDU, 
defined in table 50 (from the old SwMI), before. It shall then wait for a few seconds after which if it has still not 
received the ISI-SIMULTANEOUS MIGRATION PDU it shall send to the old SwMI a PSSl DISCONNECT 
message including the ISI-DISCONNECT PDU, defined in table 51 (see note below). The value of the 
disconnect cause in that PDU, defined in table 56, shall correspond to call restored. 

If the other end SwMI is itself engaged in an ANF-ISIIC call restoration SwMI procedure, it shall relay that 
ISI-CALL RESTORATION PDU to the new SwMI for that procedure; 

- to the old SwMI if it has received the ISI-SIMULTANEOUS MIGRATION PDU, defined in table 50 (from the 
old SwMI), before. It shall then send to the other end SwMI than the old SwMI a PSSl DISCONNECT message 
including the ISI-DISCONNECT PDU, defined in table 51, possibly after having waited for a few seconds to 
send that message (see note below). The value of the disconnect cause in that PDU, defined in table 56, shall 
correspond to call restored. 

NOTE: The main purpose of the delay for sending the ISI-DISCONNECT PDU in the first case is to leave some 
time for the detection of a possible migration of the other user into the old SwMI slightly after that of the 
first migration (of the first user into the new SwMI). A secondary purpose of that delay is to keep the ISI 
connection in case the user who has migrated into the new SwMI would migrate back into the old SwMI 
very soon. 

That secondary purpose is the only one in the second case. 

In addition, still if the new SwMI is a SwMI through which the call has been forward switched, if that new SwMI 
receives the ISI-SIMULTANEOUS MIGRATION PDU (from the old SwMI) after it has already sent the ISI-CALL 
RESTORATION PDU to the SwMI at the other end of the old SwMI, it shall send a PSSl FACILITY message 
including the ISI-CALL RESTORATION PDU, defined in table 47, to the old SwMI. 

If the new SwMI is an end SwMI, (i.e. it has received the ISI-END CALL RESTORE PREPARE PDU from the old 
SwMI), the following shall apply after that SwMI has successfully restored the call for its new visiting user: 

if it has not detected that the user previously registered in that SwMI has himself migrated into a SwMI on the 
path of the call and if it has not received the ISI-SIMULTANEOUS MIGRATION PDU (from the old SwMI), it 
shall wait for a few seconds after which it shall send to the old SwMI a PSSl DISCONNECT message including 
the ISI-DISCONNECT PDU, defined in table 51. The value of the disconnect cause in that PDU, defined in 
table 56, shall correspond to call restored; 

if it has detected that the user previously registered in that SwMI has himself migrated into a SwMI on the path 
of the call (either the other end SwMI, i.e. the old SwMI, a SwMI through which the call has been forward 
switched) or if it has received the ISI-SIMULTANEOUS MIGRATION PDU (from the old SwMI), it shall send 
a PSSl FACILITY message including the ISI-CALL RESTORATION PDU, defined in table 47, to the SwMI 
on the path of the call already mentioned. 

6.5.2.3.2.3 Failures cases of the specific call restoration procedure 

If the new SwMI has been identified by the old SwMI as being on the path of the call and does not support the 
ANF-ISIIC specific call restoration procedure (obviously it supports ANF-ISIIC in such a case - and it may or may not 
support the ANF-ISIIC general call restoration procedure), it shall send to the old SwMI a PSSl FACILITY message 
including the ROSE Return Error APDU with the cause corresponding to requestNotSupported (see subclause 6.3.3). 
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The old SwMI may then attempt the general ANF-ISIIC call restoration procedure. Otherwise it shall send the 
ISI-DISCONNECT PDU to the other end SwMI with the (ISI) disconnect cause: "ANF-ISIIC call restoration procedure 
not supported in new SwMI", possibly after having waited for a few seconds to send that message - the purpose of that 
delay is to keep the ISI connection in case the user who has migrated into the new SwMI would migrate back into the 
old SwMI very soon. 

If the new SwMI is a SwMI through which the call has been forward switched (i.e. not an end SwMI) and supports the 
ANF-ISIIC call restoration procedure (which entails that it supports the air interface call restoration procedure) but 
decides to reject the set-up from the old SwMI for any other reason (because e.g. its air interface security level cannot 
match that used at calling user air interface), it shall send to the SwMI at the other end than the old SwMI the 
ISI-DISCONNECT PDU, defined in table 51, in a PSSl DISCONNECT message, therefore clearing the call. The value 
of the disconnect cause in that ISI-DISCONNECT PDU should indicate the other reason why the new SwMI has 
decided to reject the set-up from the old SwMI. 

6.5.3 DTMF procedures 

The DTMF information shall be sent over the ISI in a PSSl FACILITY message including the 
ISI-INFO DEMAND PDU defined in table 40 (see also subclause 6.5.2.2). 

NOTE: Since according to ISO/IEC 1 1582 [18], a PSS I FACILITY can only be sent by the originating SwMI 
after a PSSl signalling path has been established (i.e. a first PSSl message has been received from the 
terminating or outgoing gateway SwMI, e.g. PSSl ALERTING, CONNECT or FACILITY message), this 
SwMI will have to store the DTMF information that it has received before. Note that this may happen 
especially as according to EN 300 392-2 [1], the air interface U-INFO PDU which carry DTMF 
information can be sent as soon a call reference has been allocated by the (originating) SwMI. 

6.5.4 ANF-ISIIC clearing 

Specific cases of ANF-ISIIC clearing have already been addressed: 

in subclause 6.5.1.2, i.e. complete clearing when the call turns out to be an intra-TETRA call, or only partial 
clearing, in case of re-routing; 

in subclause 6.5. 1 .5, because of failure of the call establishment in the terminating SwMI, or in the called SwMI 
when those two SwMIs are different (i.e. because of called user migration or supplementary service operation - 
e.g. call authorized by dispatcher or call forwarding); and 

in subclause 6.5.2.3, i.e. complete clearing when the call is restored as an intra-TETRA call, or only partial 
clearing, in case of call restoration in a SwMI already on the path of the call, different from the originating and 
terminating SwMIs). 

When the call is cleared by the calling user or by the originating SwMI before the call has been established, the PSSl 
DISCONNECT or RELEASE message sent by the originating SwMI according to the corresponding call clearing 
procedure defined in ISO/IEC 1 1572 [16] does not need to include any TETRA PDU. 

When the calling user or a TETRA application in the originating SwMI clears the call is after it has been established, 
that SwMI shall send a PSSl DISCONNECT message including the ISI-DISCONNECT PDU, defined in table 51. The 
information element disconnect cause of that TETRA PDU, defined in table 56, shall indicate the reason for that 
clearing. 

The same shall apply when the call is cleared after it has been established: 

by the connected user or a TETRA application in the terminating SwMI, to the PSSl DISCONNECT message 
sent by the terminating SwMI; 

by any TETRA application in a SwMI on the path of the call, different from the originating and terminating 
SwMIs, to the two PSSl DISCONNECT messages sent by this SwMI, one in the backwards direction (that 
towards the originating SwMI) and the other in the forwards direction (that towards the terminating SwMI). 

When the call is cleared because of failure of the PSSl network (including failure of PSSl protocol operation), no 
TETRA PDU needs to be included in the corresponding PSSl clearing message. 
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6.5.5 Call collisions 

In the case of call collision because two adjacent PISN nodes (including possibly the SwMIs involved in the call 
establishment or restoration) attempt both to seize the same PISN Bq channel the procedure defined in 
ISO/IEC 11572 [16] for call colHsion shall apply. 

In the specific case where an inter-TETRA call number 1 is being established and where the called user of this call is 
attempting to call the calling user at the same time the following shall apply: 

the two end SwMIs should identify this situation; 

then they should both compare the ITSIs of their respective calling and called users: the SwMI where the user 
with the larger ITSI number is registered shall be the leading SwMI; 

if the leading SwMI supports call amalgamation, it shall clear the ANF-ISIIC that it had invoked (for its 
outgoing ISI call attempt), amalgamate its calling user with the remaining invoked ANF-ISIIC (invoked by the 
other SwMI) and send the ISI-CONNECT PDU (in the PSSl CONNECT message) for the latter ANF-ISIIC. 
Then the other SwMI will complete the call establishment; 

NOTE 1: As a result of this procedure, the latter SwMI (i.e. the non-leading SwMI) will be the controlling SwMI. 

if the leading SwMI does not support call amalgamation, it will clear the ANF-ISIIC invoked (for its incoming 
ISI call attempt) by the other SwMI, since the called user for this invoked ANF-ISIIC is busy. Then: 

if the other SwMI does not support call amalgamation, it will also clear the remaining invoked ANF-ISIIC 
(invoked by the leading SwMI), since the called user for this invoked ANF-ISIIC is also busy; 

if the other SwMI supports call amalgamation, it shall amalgamate its calling user with the remaining 
invoked ANF-ISIIC (invoked by the leading SwMI) and send the PSSl CONNECT message for the latter 
ANF-ISIIC. The leading SwMI will then complete the call establishment; 

NOTE 2: As a result of this procedure, the leading SwMI will be the controlling SwMI. 

whether it is the leading SwMI or the other, the SwMI which amalgamates the call and sends the PSSl 
CONNECT message shall set the information element hook method selection equal to direct set-up signalling in 
the ISI-CONNECT PDU sent in this PSSl CONNECT message. 

Figure 24 illustrates the procedure just described in the case where the leading SwMI supports call amalgamation. 
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Figure 24: Call collision handling in the case where the leading SwMI supports call amalgamation 

6.6 ANF-ISIIC impact of interworking with ISDN/PISN/PSTN 

When a (TETRA) calling user requests the establishment of an external individual call through a TETRA gateway 
located in a SwMI different from that where that user is registered, the originating SwMI shall include both the ITSI 
number of this gateway and the external number in its ISI-SETUP PDU, as defined in table 26. 
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The gateway shall send to the originating SwMI the progress indicator elements and the connected number identity (if 
available) as specified in subclause 6.2.6. 

If these progress indicator elements cannot be sent either in the PS SI ALERTING or the CONNECT message, the 
gateway SwMI shall send them in a PROGRESS message. This message may also include the ISI-PROGRESS PDU 
defined in table 27, to indicate to the originating SwMI its fallback choice for some characteristics requested for the call 
in the ISI-SETUP PDU that it cannot support (i.e. duplex selection, N slot bearer requested for a data call in the basic 
service information element, speech service). If the gateway SwMI does not send such fallback choice characteristics in 
the ISI-PROGRESS PDU (in a PSSl FACILITY message), it shall send them in either the ISI- ALERTING PDU or the 
ISI-CONNECT PDU. 

The fallback choice characteristics indicated as optional in the definitions of the TETRA PDUs concerned which have 
already been sent in a previous PSSl message shall not be repeated (i.e. when identical to some already sent). 

For an external incoming individual call (i.e. to a TETRA called user) routed over the ISI, the incoming gateway shall 
send the number of the calling party in the other network if available, in its ISI-SETUP PDU as defined in table 26. It 
shall also include in this message PSSl information elements (notably the progress indicator elements) as defined in 
subclause 6.2.5. 

6.7 Protocol interactions between ANF-ISIIC and 
supplementary services and other ANFs 

6.7.1 Interaction with SS-CLIR 

In an individual inter-TETRA call, both the originating and the terminating SwMIs shall support SS-CLIR for the user 
at the other end (e.g. the terminating SwMI shall support SS-CLIR for the calling user). 

If SS-CLIR has been invoked for the calling user, the following shall apply: 

the originating SwMI shall give to the information element "Calling party presentation indicator", defined in 
subclause 6.3.2.2.12, in the ISI-SETUP PDU the value corresponding to presentation restricted; 

then, if the call is re-routed or forward switched, all ensuing ISI-SETUP PDUs shall have the same value of their 
information elements "Calling party presentation indicator"; 

if the connected user migrates during the call and registers in a new SwMI, the terminating SwMI shall give to 
the information element "SS-CLIR invoked for other party", defined in table 78, in the ISI-CALL RESTORE 
PREPARE PDU or ISI-PATH CALL RESTORE PREPARE PDU sent to the new SwMI the value 
corresponding to SS-CLIR invoked for the other party. The same requirement shall then apply to the new SwMI 
if the connected user migrates again during the call. 

If SS-CLIR has been invoked for the connected user, the following shall apply: 

the terminating SwMI shall give to the information element " Connected party presentation indicator", defined in 
subclause 6.3.2.2.16, in the ISI-CONNECT PDU the value corresponding to presentation restricted; 

if the calling user migrates during the call and registers in a new SwMI, the originating SwMI shall give to the 
information element "SS-CLIR invoked for other party", defined in table 78, in the 

ISI-CALL RESTORE PREPARE PDU or ISI-PATH CALL RESTORE PREPARE PDU sent to the new SwMI 
the value corresponding to SS-CLIR invoked for the other party. The same requirement shall then apply to the 
new SwMI if the calling user migrates again during the call. 
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6.7.2 Interactions with SS-CF 



6.7.2.1 



Interaction with SS-CF at call establishment 



When SS-CF has been invoked, the ANF-ISIIC procedure specified in subclause 6.5 shall apply in replacing the called 
user by the forwarded-to user, SwMI A being the last SwMI on the path where the call has been forward switched, 
SwMI B being the SwMI where SS-CF has been invoked and SwMI C either the home SwMI of the forwarded-to user 
or the SwMI where that user has migrated. Notably if the call is re-routed, the following shall apply for the 
ISI-REDIRECT PDU, defined in table 28, sent by the SwMI where SS-CF has been invoked: 

its corresponding SS-CF information elements shall give the ITSI of the forwarded-to user; 

its migration information elements shall be present only if the home SwMI of that user coincides with the SwMI 
where SS-CF has been invoked and if that user has migrated: they shall then indicate the SwMI where he has 
migrated. 

NOTE 1 : The preceding indented paragraph means notably that if the home SwMI of the forwarded-to user is 
different from the SwMI where SS-CF has been invoked, the corresponding the ISI-REDIRECT PDU 
sent by that SwMI if SS-CF is operated by re-routing will not include migration information elements. 

NOTE 2: If the home SwMI of the called user coincides with the originating SwMI and that user has not migrated, 
clearly the call will be an intra-TETRA call. If in such a case SS-CF has been activated for the called user 
and if the forwarded-to user is registered in a different SwMI, SS-CF will invoke an ANF-ISIIC for the 
establishment of the call. The same may hold if the forwarded-to user is registered in the originating 
SwMI, that SwMI being (still) the home SwMI of the called user but not that of the forwarded-to user. 



6.7.2.2 



Specific interaction with SS-CFNRy at call establishment 



When SS-CFNRy has been invoked, if the forwarded-to user MS/LS sends the U- ALERT PDU, this will never result in 
the PSSl ALERTING PDU being sent twice on the same signalling connections. Therefore the accompanying 
ISI- ALERTING PDU, defined in table 30, shall not be sent twice across those same signalling connections. The 
ISI-INFO DEMAND PDU, defined in table 40, may be sent instead. 



6.7.2.3 



Interaction with SS-CF at call restoration 



There shall be no interaction between ANF-ISIIC with SS-CF at call restoration, i.e. when a user migrates and registers 
in a new SwMI during an individual inter-TETRA call established with or more call forwardings, the call restoration 
procedure shall be the same as that described in subclause 6.5.2.3. 

This holds notably when the new SwMI coincides with a SwMI on the call path, i.e.: either some forward switching 
SwMI if the call has been forward switched or the other end SwMI (terminating or originating SwMI). 

NOTE 1 : There is however a difference between call restoration of an individual inter-TETRA call established with 
or without call forwarding: for the latter only a trombone connection could result when the new SwMI 
coincides with a SwMI on the call path in the absence of trombone or loop detection by ANF-ISIIC, while 
a genuine loop connection may occur if many SS-CF have been invoked and more than one has been 
operated by forward switching. Such a case will arise when e.g. the connected user migrates either in an 
"upstream" forward switching SwMI (on the call path) or in the originating SwMI. 

NOTE 2: The ISI trombone or loop connection detection recommended for the ANF-ISIIC call restoration should 
avoid such connection: 

in the case where call restoration happens for the connected user in the originating SwMI, or for the 
calling user, in the terminating SwMI; 

in the case where call restoration happens for the calling user in the forward switching SwMI just after 
the originating SwMI on the call path; and 

in the case where call restoration for the connected user in the forward switching SwMI just before the 
terminating SwMI on the call path. 
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Unfortunately, ANF-ISIIC will not be capable to detect a trombone or loop connection resulting from migration when 
the new SwMI coincides with any other forward switching SwMI. The reason for that is that neither the originating nor 
the terminating SwMIs are informed about all (forward switching) SwMIs on the call path. 

6.7.3 Interaction with SS-CAD 

6.7.3.1 Invocation of a specific ANF-ISIIC 

When SS-CAD is invoked for an outgoing individual call and when the dispatcher is located in another SwMI, a 
specific ANF-ISIIC shall be invoked if the operation of SS-CAD entails the establishment of a call between the calling 
user and the dispatcher (i.e. diversion to the dispatcher). The corresponding TETRA PDU included in the PSSl SETUP 
message for that call shall be the standard ISTSETUP PDU (defined in table 26), i.e. no specific information element 
identifying this type of call shall be added to this TETRA PDU. 

NOTE: Actually the PSS 1 SETUP message will carry a specific SS-CAD PDU (CAD REQUEST PDU) in 
addition to the ISI-SETUP PDU - which is not an interaction. 

The same shall apply if SS-CAD is invoked for an incoming individual intra-TETRA call and if the dispatcher is 
located in another SwMI. 

6.7.3.2 Interception of an already invoked ANF-ISIIC 

If SS-CAD has been invoked for an inter-TETRA individual call, the interaction between ANF-ISIIC and SS-CAD shall 
depend on whether or nor SS-CAD operation entails the establishment of a call between the calling user and the 
dispatcher (i.e. diversion to the dispatcher). 

If not, the invoked ANF-ISIIC shall simply be suspended in the SwMI where SS-CAD has been invoked. If yes, the 
corresponding call to the dispatcher shall be established by the ANF-ISIIC invoked for this inter-TETRA individual 
call: i.e. no additional ANF-ISIIC shall be invoked. To establish this call if the dispatcher is registered in a SwMI 
different from the SwMI where SS-CAD has been invoked, the already invoked ANF-ISIIC shall send the PSSl SETUP 
message including the ISI-SETUP PDU, defined in table 26, and a specific SS-CAD PDU: CAD REQUEST PDU. The 
ensuing call to the dispatcher shall be established by forward switching (through the SwMI where SS-CAD has been 
invoked). 

The information element "call diverted to a dispatcher" in the ISI-CONNECT PDU defined in table 31, sent in the PSSl 
CONNECT message when the call is established with the dispatcher shall be set on. 

NOTE: This caters for the case where the originating SwMI would not support SS-CAD, but would support e.g. 
SS-TPI or lawful intercept. 

6.7.3.3 Call authorization by a distant dispatcher 

If the dispatcher is registered in a SwMI different from the SwMI where SS-CAD has been invoked and if a call has 
been established between the calling user and the dispatcher, to authorize the establishment of the call originally 
requested to be resumed, the dispatcher SwMI shall send a PSSl FACILITY message including a specific 
SS-CAD PDU: CAD ACCEPT PDU. That message shall be addressed to a PISN number which identifies the SwMI 
where SS-CAD has been invoked (i.e. where diversion to the dispatcher was initiated). This PISN number shall be 
determined using the MNI value of the SwMI received in the CAD REQUEST PDU mentioned in subclause 6.7.3.2. 

6.7.3.4 Completion of call establishment 
6.7.3.4.1 Call not diverted to dispatcher 

Upon receiving the authorization to resume the call establishment, if the call has not been diverted to a dispatcher (i.e. 
no PSS 1 CONNECT message has yet be sent to the originating SwMI) and if the called user has migrated, the call 
establishment shall proceed as defined in subclause 6.5.1, starting from subclause 6.5.1.2. 
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6.7.3.4.2 Call diverted to dispatcher 



Upon receiving the authorization to resume the call establishment, if the call has been diverted to a dispatcher and if the 
called user has migrated, the diverting SwMI shall send to the terminating SwMI the PSSl SETUP message including 
the ISI-SETUP PDU, defined in table 26. 

The contents of that ISI-SETUP PDU shall be the same as if the call had simply been forward switched and not been 
established before with the dispatcher (see paragraph a) of subclause 6.5.1.2.1), except for the value of the information 
element transmission grant. The latter value shall be set in such a manner that it does not result in any change of 
transmission permission granted to the calling user, i.e.: 

if the calling user had been granted permission to transmit when the dispatcher authorizes the establishment of 
the call to be resumed, the diverting SwMI shall give to the information element transmission grant the value 
corresponding to transmission granted to another user (see table 126 of EN 300 392-2 [1]); 

if it is the dispatcher who had been granted permission to transmit when the dispatcher authorizes the 
establishment of the call to be resumed, the diverting SwMI shall give to the information element transmission 
grant the value corresponding to transmission granted (see table 126 of EN 300 392-2 [1]). 

If the diverting SwMI is different from the originating SwMI, it shall: 

- send a PSS 1 FACILITY message including the ISI-TROUGH ALERTING PDU defined in table 52 to the 
originating SwMI if it receives from the terminating SwMI the PSSl ALERTING message including the 
ISI-ALERTING PDU (defined in table 30); 

- send a PSS 1 FACILITY message including the ISI-TROUGH CONNECT PDU defined in table 53 to the 
originating SwMI when it receives from the terminating SwMI the PSSl CONNECT including the 
ISI-CONNECT PDU (defined in table 31). 

The diverting SwMI shall then join the connection of the new call to the called/connected user with that of the 
original call from the calling user (through the originating SwMI) diverted to a dispatcher. In addition if that 
dispatcher was registered in a SwMI different from the diverting SwMI, the diverting SwMI shall send a PSSl 
DISCONNECT message to the dispatcher SwMI to clear the connection of the original call with the dispatcher. 

Whether or not it supports SS-CAD, the originating SwMI shall recognize the PSSl FACILITY messages including the 
ISI-TROUGH ALERTING PDU, defined in table 52, and the ISI-TROUGH CONNECT PDU, defined in table 53, sent 
by the diverting SwMI as the true PSSl ALERTING and CONNECT messages for the original call, respectively 
(including the ISI-ALERTING PDU, defined in table 30, and the ISI-CONNECT PDU, defined in table 31, 
respectively). Notably: 

- upon receiving that PSS 1 FACILITY message including the ISI-THROUGH CONNECT PDU, defined in 
table 53, it shall send to the terminating SwMI a PSSl FACILITY message including the 
ISI-CONNECT ACKNOWLEDGE PDU, defined in table 34; 

the originating SwMI shall detect if any modification has occurred in the bearer service definition (i.e. change in 
the simplex/duplex selection, in the basic service or of CODEC) by analysing the contents of the corresponding 
information elements in the received ISI-TROUGH ALERTING or ISI-THROUGH CONNECT PDUs. 

NOTE: The provision in the last paragraph is in line with the requirement in the stage 1 description (see 

subclause 4.3.11) that the originating SwMI has to handle the set-up response that it receives as if no 
interception by the dispatcher had taken place; using stage 3 description terminology, this means as if it 
had received this response from the terminating SwMI in the PSSl CONNECT message. 

If the called user has migrated and is registered in the originating SwMI, then to avoid the overriding of dispatcher 
authorization by a local SS-BIC, the information element incoming call barring status, defined in table 66, in the 
ISI-REDIRECT PDU (see table 28) shall be set to call authorized by SS-CAD. 

6.7.4 Interactions with SS-PC, SS-PPC and SS-CRT 

To be defined. 
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6.7.5 Interaction with SS-CW 



As already mentioned in subclause 6.7.2.1 the PSSl ALERTING PDU will never be sent twice on the same signalling 
connections. Therefore when, after SS-CW has been invoked by a user MS/LS, that MS/LS sends the U-ALERT PDU 
(after having become idle), the ISI-ALERTING PDU, defined in table 30, shall not be sent twice. The ISI-INFO 
DEMAND PDU, defined in table 40, may be sent instead. 

NOTE: The definition of the information element call status, in table 54, has taken into account the possibility to 
inform the originating SwMI that SS-CW has been invoked using the ISI-ALERTING PDU, else the 
ISI-INFO DEMAND PDU. 

6.7.6 Interaction with SS-HOLD 

No interaction. 

NOTE: The definition of the information element call status, in table 54, has taken into account the possibility to 
inform the other SwMI that SS-HOLD has been invoked using the ISI-INFO DEMAND PDU. 

6.7.7 Interaction with SS-CCBS and SS-CCNR 

The only interaction between ANF-ISIIC and SS-CCBS or SS-CCNR lies in the possibility for the originating SwMI to 
override the invocation of SS-CAD for the SS-CCBS or SS-CCNR recall (i.e. new call for successful SS-CCBS or 
SS-CCNR operation) if SS-CAD had been invoked for the failed call attempt which has resulted in SS-CCBS or 
SS-CCNR being invoked. Such overriding request shall be sent (by the originating SwMI) in the ISI-SETUP PDU using 
the information element override SS-CAD invocation, defined in table 69. 

6.7.8 Interaction with SS-BIC 

There is no protocol interaction when the terminating SwMI is the SwMI first called by the originating SwMI (because 
either the terminating SwMI is the called user home SwMI and this user has not migrated, or the originating SwMI is 
the called user home SwMI). 

When the home SwMI of the called user is different from the originating SwMI, when this user has migrated and when 
SS-CAD for incoming calls has not been invoked, the invoked ANF-ISIIC has to ensure the operation of SS-BIC for the 
incoming call in the called user home SwMI unless a local SS-BIC applies (which overrules the "general" SS-BIC). 
Such local SS-BIC can only apply if the called user is registered in the originating SwMI (after having migrated). 
According to subclause 6.5.4, this will be detected by the invoked ANF-ISIIC in the called user home SwMI (using the 
originating SwMI Mobile Network Identity (MNI)), which will then send a PSSl FACILITY message including the 
ISI-REDIRECT PDU defined in table 28. 

Consequently, the protocol interaction between ANF-ISIIC and SS-BIC consists only in having the information element 
incoming call barring status in that ISI-REDIRECT PDU set to either call barred by SS-BIC or call authorized by 
SS-BIC (see table 66). 

NOTE: This applies only if SS-CAD for the incoming call has not been invoked, since it overrides SS-BIC. 

6.7.9 Interactions with SS-AoC 

If an advice of charge supplementary service is invoked for an inter-TETRA call at its set-up and if some charging 
information is to be got from another SwMI for operating that supplementary service, a specific SS-AoC PDU shall be 
included in the PSSl SETUP message. 

When the supplementary services SS-AoC-E or AoC-D have been invoked, independently of whether this is per call or 
for all calls, when the served user clears the call, instead of sending a PSSl DISCONNECT message, the SwMI serving 
this user (e.g. the originating SwMI) shall send a PSSl FACILITY message including a specific SS-AoC PDU to 
request charging information from other SwMI(s) on the path (e.g. the gateway or terminating SwMI) and to and to 
clear the call in delivering such information. 

The charging information at the end shall be included in a specific SS-AoC PDU sent by the other end SwMI sent 
together with the ISI-DISCONNECT PDU defined in table 51 in a PSSl DISCONNECT message. 
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6.7.1 Interactions with otiner supplementary services 

At the time of the writing of the present document, no other supplementary service has been identified which would 
require for its invocation or its operation an interaction with ANF-ISIIC. 

NOTE: Such supplementary services require only the transport of their PDUs (i.e. SS PDUs) through ANF-ISISS, 
as defined in clauses 9 and 10 of EN 300 392-9 [5]. 

6.8 ANF-ISIIC parameter values (timers) 

ANF-ISIIC shall use the mandatory timers defined in ISO/IEC 1 1572 [16]. It shall not use the optional PSSl timer 
T301 (for the outgoing side, started by the reception of the PSSl ALERTING message, and stopped by that of the PSSl 
CONNECT message (since it might conflict with the call set-up phase TETRA timer). 

In addition, ANF-ISIIC shall use timer Tl as defined in subclause 6.5.2.3, to protect against too much delay of call 
restoration while a connection between the old SwMI and the new SwMI has been established. The minimum value of 
this timer shall be 5 seconds, and its maximum value, 30 seconds. 
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Annex A (informative): 

Static description of the TETRA individual call bearer 

service, using attributes 

Reformulating the corresponding information defined in EN 300 392-2 [1] leads to the static description of TETRA 
bearer service attributes given below using the relevant attributes with the corresponding values as defined in ITU-T 
Recommendation 1.140 [12]. 



1) Information transfer mode: 

2) Information transfer rate: 

3) Information transfer capability: 

4) Structure: 



circuit. 



from 2,4 kbit/s up to 4 x 7,2 kbit/s (= 28,8 kbit/s) (in the case of data 
transmission) - see 14.8.2 of EN 300 392-2 [1]. 

all TETRA circuit mode bearer and tele- services. 

for single slot communications: "service data unit integrity" for 
telephony calls and for end-to-end encrypted data calls, and 
"unstructured" for other data calls; 

for multislot communications: "Time Slot Sequence Integrity" (TSSI). 

NOTE: According to subclause 4.5.1 of EN 300 392-2 [1] the air interface time slots comprise 510 bits (possibly 
only half, in special cases), sent at a data rate of 36 kbit/s (hence a timeslot duration of 14,167 ms). 
Depending on the type of traffic channel that they carry, these 510 bit time slots carry layer 3 service data 
units possibly completed by error control bits and interleaved between N time slots of different lengths 
(e.g. 432 bits for 7,2 kbit/s traffic channel, or 288 bits for 4,8 kbit/s traffic channel). The above statement 
about the value of the attribute structure in the case of telephony calls and of end-to-end encrypted data 
calls means that the corresponding layer 3 service data units have to be delivered transparently to the 
destination access point. 

On the other hand, it is clear that the order of the time slots at the air interface should be kept end-to-end 
in multi-slot communications, hence the structure "TSSI". 



5) Establishment of communication: 

6) Symmetry: 

7) Communication configuration: 

8) Access channel and rate: 

9) Access protocol: 

10) Supplementary services provided: 

11) Quality of service: 

12) Interworking capability: 

13) Operational and commercial aspects: 



demand. 

bi-directional symmetric for duplex operation, and unidirectional for 
half-duplex operation. 

point-to-point (since the communication is an individual call). 

TDMA timeslot, at a rate of 9 kbit/s. 

air interface protocols for both signalling and user information - as 
defined in EN 300 392-2 [1]. 

in line with ITU-T Recommendation 1.210 [13], the definition of the 
value of this attribute is under study. 

in line with ITU-T Recommendation 1.210 [13], the definition of the 
value of this attribute is under study. 

according to ITU-T Recommendation 1.140 [12], the possible values of 
this attribute remain to be defined. 

according to ITU-T Recommendation 1.140 [12], the possible values of 
this attribute remain to be defined. 
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Annex B (informative): 

Definition of the ISI ROSE operation 

Table B.l reproduces table 16 of ETS 300 392-3-1 [2]. In case of discrepancy, the latter applies. 
Table B.1 : ROSE operation in support of TETRA encoding PDU 



TetralsiOperation {ccitt (0) identified-organization (4) etsi (0) tetra(392) isi-encoding-operation(O) } 

DEFINITIONS EXPLICIT TAGS ::= 

BEGIN 

IMPORTS OPERATION, ERROR FROM Remote-Operations-Notation 

{joint-iso -ccitt (2) remote-operations (4) notation (0) }; 

TetraIsiMessage::= OPERATION 

— TETRA ANF-ISI message encoded in the argument 
ARGUMENT IsiArgument 
RESULT IsiResult 
ERRORS { incompleteTetraPDU, requestNotSupported, invalidlnfoElement, unspecified } 

— Definition of general used data types: 

IsiArgument 

::= SEQUENCE { 

sourceEntity [0] IMPLICIT AnfSubEntity, 

destinationEntity [1] IMPLICIT AnfSubEntity, 

tetraMessage [2] IMPLICIT OCTET STRING 

} 
IsiResult 

::= CHOICE { 

NULL, 
IsiArgument 

} 
incompleteXetraPdu ERROR 

PARAMETER ErrorOctetString 

itsiNotRegistered ERROR 

::=2 
itsiNotReachable ERROR 

::=3 
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requestNotSupported ERROR 

PARAMETER ErrorRequestNotSupported 

::=4 
invalidlnfoElement ERROR 

PARAMETER Errorlnvalidlnfo 
::=5 
unspecified ERROR 

::=0 

AnfSubEndty ::= ENUMERATED {anflsiss (1), anflsimm (2), anflsiic (3), anflsigc (4), anflsisd 

(5), anflsiCallUnrelatedSignalling (6)} 

ErrorOctetString 

::= SEQUENCE { 

octetstring[0] IMPLICIT OCTETSTRING 



ErrorRequestNotSupported 

::= CHOICE { 

mmRequestNotSupprted 
ssRequestNotSupprted 



MMRequestNotSupported, 
SSRequestNotSupported 



MMRequestNotSupported 

::= [0] IMPLICIT OCTET STRING 
SSRequestNotSupported 

::= CHOICE { 

[1] IMPLICIT ListSSNotSupported, 

[2] IMPLICIT ListSSActionNotSupported, 

[3] IMPLICIT CombinedSSListNotSupported 

} 
ListSSNotSupported : := OCTET STRING 
ListSSActionNotSupported 

::= CHOICE { 

[4] IMPLICIT SSActionNotSupported, 

[5] IMPLICIT SEQUENCE OF SSActionNotSupported 

} 
SSActionNotSupported 

::= SEQUENCE { 

ssType [6] IMPLICIT OCTET STRING, 

ssPduType [7] IMPLICIT OCTET STRING 

} 
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CombinedSSListNotSupported 

::= SEQUENCE { 

listSSNotSupported ListSSNotSupported, 
listSSActionNotSupported ListSSActionNotSupported 

} 
Errorlnvalidlnfo 

::= CHOICE { 

[0] IMPLICIT InvalidlnfoType, 

[1] IMPLICIT SEQUENCE OF InvalidlnfoType 

} 
InvalidlnfoType 

::= SEQUENCE { 

PDUIndicator [2] IMPLICIT OCTET STRING, 
elementType [3] IMPLICIT INTEGER (L.3), 
elementPosition [4] IMPLICIT INTEGER 



tetralsiMessage TetralsiMessage ::= I 



END -- OF TetralsiOperation 
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